Frontend links may not use correct domain

[dale-wahl]

Describe the bug
Unsure if this is in fact two issue and perhaps related to nginx/apache configuration...

Something is off with Flask's url_for when used internally (i.e. not via a request). Example here:

It shows the IP address instead of the correct domain (looks internal network IP). This is from the King's server at https://4cat.er.kcl.ac.uk. Perhaps there are some setting necessary in configuring whatever intermediary to pass correct proxy headers?

There is another issue that is probably not exactly related, but it is on the same server and I mention in case it is also a result of configuration of their intermediary. Certain endpoints result in 403 errors such as attempting to save settings (post to admin/settings?tag=). Sending a new password link results in a 500 series error (admin/add-user/?force=1&format=html&email=my@email). Hopefully I can get the frontend logs and at least see if it is 4CAT or, perhaps, their intermediary. I am not sure of a pattern connecting those two endpoint and seem to be able to do other things like create datasets/processors fine.

To Reproduce
Unsure.

4CAT Environment
Docker deployment, 4CAT upgraded recently to v1.39. It was upgraded from something like v1.33 (a version prior to much of the settings additions so unsure if the issue is new or would have existed then as well). Unsure if Nginx, Apache, or other is being used.

[stijn-uva]

Perhaps there are some setting necessary in configuring whatever intermediary to pass correct proxy headers?

It does sound like a reverse proxy issue. We do have these, in 'Flask settings':

[dale-wahl]

I think that explains the "Sending a new password link" that results in a 500 series error (admin/add-user/?force=1&format=html&email=my@email) error. That format=html results in a url_for call that would fail.

I cannot figure out why calls to admin/settings?tag= would result in 403 though. Specifically posts as you can view the settings page fine. It's not the admin path as far as I can tell as other posts work to other admin endpoints. I wonder if their infrastructure happens to have an admin/settings path and thus a rule to stop posts there...

I suppose I could recommend some direct db update like update settings set value='["x_for", "x_proto", "x_host", "x_port", "x_prefix"]' where name='flask.proxy_override' since they cannot currently update their settings via the frontend. I am not sure our implementation will effect gunicorn though gunicorn does have a wsgi_app argument so we may be able to fix that if not.