Ah, I see that it works differently in other shells. The above output was from zsh. In bash, indeed all output is written to the file:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 16 2017
It shows no output because there are no warnings. If you replace phabricator/bin/storage dump with a command that does give various formats of warnings on stderr, you see that it works:
$ sh -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning) error error2 $ cat foo.txt output1 output2
I used the subshell redirection trick as mentioned by @epriestley to hide this warning from our cron output as well:
Jan 18 2017
Aug 22 2016
FWIW, in our case the bug was also triggered by logging in for the first time (for this account) using LDAP.
Jul 7 2016
I just had this problem as well. Turns out I had a typo in preamble.php. A more descriptive error would be nice, but with this task open at least the cause is easy to find :)
Note that it is possible to set a path to the websocket for every server as well. This is handy, for example, when your notification websocket is hosted behind the same URL as Phabricator itself. We have https://phabricator.ourcompany.net/ for Phabricator itself, and https://phabricator.ourcompany.net/ws/ for the notifictions websocket. This corresponds to the following client config:
Mar 30 2016
In T9293#167654, @epriestley wrote:Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."
In T9293#167652, @epriestley wrote:$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.
In T9293#167637, @epriestley wrote:We will not trust X-Forwarded-Proto, X-Forwarded-For, etc., by default because they are not trustworthy in the general case (they are completely client-controlled if you aren't behind a load-balancer).
Mar 6 2016
Dec 25 2015
Dec 16 2015
Aug 31 2015
T8982 is somewhat related, since it is about wrong parsing of notification.client-uri (but it is not related in that it may have the same fix).
commit 33c3ebe0606580efc22c410f654a9fa76655779a Author: Sjors Gielen <sjors@sjorsgielen.nl> Date: Mon Aug 31 17:29:00 2015 +0200