Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Fineract enforces being used by an HTTPS URL (e.g. on 8443), and redirects any HTTP requests (e.g. on 8080) to HTTPS, using HTTP/1.1 302 Found. This is a good out of the box default best practice for security.
However, in certain deployment scenarios, one wishes to use Fineract and let something else than the Tomcat running the Fineract Java code do SSL. As briefly described e.g. on https://en.wikipedia.org/wiki/TLS_termination_proxy, this is typically another web server (such as e.g. Apache or Nginx, or something like) that which is acting as SSL Proxy. In such environments, while an end-user still uses Fineract via HTTPS, Fineract must be able to handle HTTP (not HTTPS) requests received from the intermediate server without SSL and without redirecting.
I learnt in https://github.com/alfio-event/alf.io/issues/511#issuecomment-424015471 (and https://github.com/alfio-event/alf.io/issues/632) that such TLS termination proxies for SSL offloading typically set the X-Forwarded-For and X-Forwarded-Proto HTTP headers, as documented e.g. on https://docs.spring.io/spring-boot/docs/1.5.16.RELEASE/reference/htmlsingle/#howto-use-tomcat-behind-a-proxy-server.
But this does not work in Fineract today. This can be seen e.g. when running Fineract on a Cloud Provider which offers its own SSL Termination, such as e.g. on (my) https://www.fineract.dev, which today is broken because of this problem. (It should probably also be possible to somehow locally reproduce this by installing and appropriately configuring an SSL proxy.)
Attachments
Issue Links
- blocks
-
FINERACT-786 Fineract on Google Cloud ("managed", with Cloud SQL)
-
- Open
-
- is blocked by
-
-
- Resolved
-
- relates to
-
-
- Resolved
-
- links to