You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just tested the new code handling the BASE_URL parameter in production. Some problems occured:
Setting a hostname in BASE_URL leads (in some cases) to Flask failing to bind the socket, since it tries to resolve the hostname. It seems that Flask is not using the SERVER_NAME field for URL generation, but also for socket setup.
Setting the PREFERRED_URL_SCHEME does not affect the resulting URLs. All URLs are now generated with 'http' scheme, despite being set to 'https' via BASE_URL/PREFERRED_URL_SCHEME.
The text was updated successfully, but these errors were encountered:
I looked around and found wilbertom/flask-reverse-proxy, which is based on Flask snippet #35. I am not completely happy with their implementation -- not that they use non-standardized headers, but also they don't use the 'de-facto' standards X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto.
For now, implementing this in om-parser-stw-potsdam-v2 is not urgent, since my current production environment config only 'fails' by generating 'http://' URLs, but these get redirected to 'https://' by my front-end load balancers whenever they are accessed. Since we are talking about public information published at these URLs, HTTPS is not strictly needed and the security implications of using HTTP are negligible.
Whatever your operational requirements exactly are, feel free to implement & adapt. I encourage you to think in all directions, including swapping out Flask for another web (micro) framework. After all, it is very well feasible at this toy project size. It might be less effort than forking other modules in order to provide functionality to Flask which is supposedly missing - put in as much work as you want 😉
Just tested the new code handling the
BASE_URL
parameter in production. Some problems occured:BASE_URL
leads (in some cases) to Flask failing to bind the socket, since it tries to resolve the hostname. It seems that Flask is not using theSERVER_NAME
field for URL generation, but also for socket setup.PREFERRED_URL_SCHEME
does not affect the resulting URLs. All URLs are now generated with 'http' scheme, despite being set to 'https' viaBASE_URL
/PREFERRED_URL_SCHEME
.The text was updated successfully, but these errors were encountered: