BASE_URL environment handling is not functional

[kaifabian]

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.

[kaifabian]

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.

Right now, I am thinking about forking that module and adapting it, so that it supports both the de-facto-standard X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, but also the standardized Forwarded header from RFC 7239, which supersedes those three.

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.

[f4lco]

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 😉