Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-8661

Magnolia does not honor X-Forwarded-Proto header processing redirections

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Fix
    • Neutral
    • None
    • 6.2.26
    • None

    Description

      Description

      The X-Forwarded-Proto header is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer. In deployments where a proxy (e.g. Fastly in PaaS) acts as TLS terminator with the clients but the proxy connects with Magnolia using http, Magnolia process the redirections using http. However, when Magnolia receives the X-Forwarded-Proto header, it should create the redirections using https, considering it received the X-Forwarded-Proto = https.

      Steps to reproduce

      1. Create a rewrite rule (in Magnolia) to redirect /events.html into /about/events.html
      2. Access to http://localhost/events.html (with the correct port and context) with Postman (or curl) using http and sending X-Forwarded-Proto = https
      3. Magnolia returns a 301 response to http://localhost/about/events.html

      Expected results

      The redirection should be to https://localhost/about/events.html

      Development notes

      The class RequestDispatchUtil creates the new URL with this code:

       if (isInternal(permanentUrl)) {
                          if (isUsingStandardPort(request)) {
                              permanentUrl = new URL(
                                      request.getScheme(),
                                      request.getServerName(),
                                      request.getContextPath() + permanentUrl).toExternalForm();

      The problem is that request.getScheme() returns http, as the connection with Magnolia uses http. We should use the header X-Forwarded-Proto if it is set. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto

      Reading about how Fastly behaves (https://docs.fastly.com/en/guides/tls-termination), it seems it uses a different header and different value for notifying that the client is using https, so it seems it is needed to either allow configuring the value of the header and the value that corresponds to https or maybe add different strategies and allow configuring one.

      Checklists

        Acceptance criteria

        Attachments

          Activity

            People

              mstrucka Marek Strucka
              jalonso Jesus Alonso
              DeveloperX
              Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Work Started:

                Checklists

                  Bug DoR
                  Task DoD