If user uses nginx(ssl) for phabricator proxy, phabricator request protocol is "http".
see this source, you can find bug. It should be changed like this.
$request->isHTTPS()
to
$client_uri->getProtocol() == "https"
Description
Description
Revisions and Commits
Revisions and Commits
Related Objects
Related Objects
- Mentioned In
- T11103: Browser do not connect to aphlict (notification) server using ssl terminating nginx reverse proxy
T10751: Make Phabricator Highly Available - Mentioned Here
- D15961: Detect timezone discrepancies and prompt users to reconcile them
T2226: Include a setup test for gzip enabled on the server
T3025: Detect when browser and account timezone settings differ and prompt user to reconcile them
Event Timeline
Comment Actions
To clarify, you are using HTTP for Phabricator but HTTPS for the notification server? If so, why have you made this (unusual) configuration choice?
Comment Actions
I use nginx for reverse proxy in front.
client -> nginx(https) -> phabricator/apache(http) docker container
So client connect with ssl, but phabricator sever receive not ssl.
Comment Actions
So your client is sending an HTTPS request, but $request->isHTTPS() is false?
This is a misconfiguration.
See "Adjusting SSL" here for one approach to fixing it:
https://secure.phabricator.com/book/phabricator/article/configuring_preamble/
Comment Actions
Some things we can do easily here:
- Modify the "Notification Servers" panel to show which servers are connectable and make it clear when there's an HTTP vs HTTPS mismatch.
- Examine the X-Forwarded-Proto header -- without trusting it -- and use it to raise a setup warning about HTTP vs HTTPS mismatches.
That won't cover cases where SSL is silently terminated by nginx, or by some other loadbalancer-like reverse proxy that doesn't add X-Forwarded-Proto.
We can detect all cases of HTTP/HTTPS mismatch by having the client examine the URI, then tell the server what it's using. However, we have to do this with Javascript and can't easily do it at the same time as we run other setup issues.
It's also not straightforward to figure out when to perform this check. The standard server-side setup issues may be triggered by, e.g., a loadbalancer health check request to /status/, but this is an inappropriate time to do HTTPS checks.
This might actually be more similar to T3025, basically:
- When rendering a page, send the HTTP/HTTPS setting to the client (and, in T3025, the timezone setting).
- If they differ, prompt the user to reconcile them.
Other vaguely-similar setup issues might be language settings and date-time preferences. Even if we can infer these from "Accept:" headers, prompting the user to reconcile them is likely the best course of action.
See also T2226, etc., for a vaguely related additional class of setup check (where we must test a server response).
Comment Actions
@epriestley am I good to take a stab here at implementing the T3025-like behaviour?
If user is admin and clientProto != serverProto, display notification.
Approximately 5% familiar with Phabricator's JS side, but always interested in poking around more of the codebase - and I'm guessing most of this is gonna be touched in D15961.
Comment Actions
Yeah, I think something similar to D15961 is reasonable here. It's going to a little bit one-off and weird, but this and the timezone checks are the only cases where we care about client settings, I think.
Ideally we'd do some kind of magic to just turn this into a normal client setup check somehow, but I don't really see any reasonable pathway toward that which doesn't run us into a huge fragile mess.