DASH_PROXY

[alexcjohnson]

app.run_server looks for a new env var DASH_PROXY and uses this to:

• fix the startup message ("Running on http://127.0.0.1:8050/") if this isn't actually where you need to go to see your app.
• and verify the app is being served on the same protocol, host, and port you are proxying.

DASH_PROXY should look like {input}::{output}, eg: http://0.0.0.0:8050::https://my.domain.com

• I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR
• I have added entry in the CHANGELOG.md

[alexcjohnson]

We don't do all that much with self.logger but what we do we always want the user to see - not just when silencing built-in route logging.

[alexcjohnson]

Are we happy with proxy errors throwing, or would it be better to just show a warning but keep going?

[Marc-Andre-Rivet]

I'm not sure I understand this: If we throw an error when the served_url portion of DASH_PROXY does not match what's already available in protocol/host/port either through defaults or env variables, why force the user to provide it in the first place? Why not just reuse what we already have and use DASH_PROXY only for the proxied url part?

[alexcjohnson]

DASH_PROXY presumably comes from some system configuration at a level that's inaccessible to Dash itself, it's just being reported by the environment as something Dash needs to obey.

But I guess that brings up the option to do the reverse of what you're suggesting: ignore host and port when we have a DASH_PROXY - maybe throw a warning or an error if the user tries to override those and they conflict with the proxy, otherwise just run with the values indicated by the proxy.

I don't think we can do that with the protocol, because if you're using https you also need to provide the cert and key. But I get the impression (@gzork can you confirm this?) that at least in our own use of such proxies, encryption is handled by the proxy itself so DASH_PROXY will look like http://<local>::https://<public>. So if the user did provide ssl_context when the proxy indicates http it would be an error but that's unlikely to happen accidentally. And the reverse won't happen if the proxy is handling encryption and this is correctly reflected in DASH_PROXY.

[deepstqte]

at least in our own use of such proxies, encryption is handled by the proxy itself so DASH_PROXY will look like http://::https://.

That's correct, in our case the encryption is handled by haproxy on the Dash Enterprise server, and I think it's safe to generally also assume that it will be handled by the proxy itself, a note either in the docs or elsewhere would still be good though.

[alexcjohnson]

The complete message you get now (ours plus the built-in Flask message) looks like:

$ python app1.py
Dash is running on http://127.0.0.1:8050/

 Warning: This is a development server. Do not use app.run_server
 in production, use a production WSGI server like gunicorn instead.

 * Serving Flask app "app1" (lazy loading)
 * Environment: development
 * Debug mode: on

[Marc-Andre-Rivet]

One question/comment about DASH_PROXY relationship with other env variables but don't have a strong opinion of my own on how this integrates with other systems. Otherwise seems fine.

[deepstqte]

It looks good to me.

I haven't thought about this earlier, but I now wonder if it's worth having both the served url and proxied url; having the served url allows to verify of that corresponds to the parameters (protocol, host and port), but if DASH_PROXY (or it could be under a different name in that case) had only the proxied_url then we'd just print that.

I guess this would lead us to the question; Aside from printing the right url for the app, do we care about validating the served url/parameters ?

[alexcjohnson]

Aside from printing the right url for the app, do we care about validating the served url/parameters?

Unfortunately I think we do need all the information scattered between the separate vars ssl_context, host, port, and both sides of proxy. For local uses you don't have a proxy, and there are distinct purposes to each of the first three, so we need those. And when you have a proxy, its setup lives outside of Dash's control, so the best we can do is check the proxy and verify that we're doing what it requires - which requires the input side of the proxy, and the output side is needed for printing the correct url.

I suppose an alternative to throwing an error when the local settings don't match the proxy would be to just ignore the local settings and use the proxy. That wouldn't change the variables at all, just how and when they're used. That feels a bit too magical to me but I could be convinced.