Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-45539

Support X-Forwarded-Proto and Forwarded headers in is_https

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Won't Do
    • Icon: Minor Minor
    • None
    • 2.5.6, 2.7, 2.8.9, 2.9.3, 3.0
    • Authentication, Libraries

      As described below, ssl proxy and loginhttps cannot be used in conjunction, and it is not well documented. As part of this issue we need to

      1. Look at the defacto X-Forwarded-Proto and the standard Forwarded http request headers (used by load balancers/reverse proxies) to is_https (lib/weblib.php) if a certain config setting is enabled.
        This negates the need to use $CFG->sslproxy to use a load balancer with https. Admins can configure their load balancer to send the original request information in the request to moodle and then we can determine the protocol of the request from the request headers.
        We may need to add a config setting or just use $CFG->reverseproxy. $CFG->reverseproxy adds more freedom in what requests are accepted than $CFG->sslproxy did so we may want to add a new setting. We cannot just blindly use the request headers as they can be easily forged by anyone.
      2. Start using is_https() in set_url() (lib/pagelib.php) which will allow the use of $CFG->loginhttps with $CFG->reverseproxy as we can determine if the original request was over https or http using the headers.
      3. Improve & update the documentation surrounding the use of sslproxy, reverseproxy and loginhttps
      4. Improve comments in code and config-dist.php

      Hi,

      I have an SSL certificate installed on a load balancer that handles all of the SSL overhead and allows moodle to operate on HTTP via port 80. We are looking to move the entire site over to https via the scheme in $CFG->wwwroot. In the mean time, we are having to support content (in iframes) served from http - which browsers will block. Perhaps this is a valid use case of using $CFG->sslproxy AND $CFG->httpslogin.. to get the (perhaps questionable) benefit of enforcing users to login via HTTPS, but still being able to serve all content.

      I have created a local patch in (2.5) lib/setuplib.php that looks like this:

      //There are two use cases when an SSL proxy (such as a certificate being installed on a load balancer) is enabled:
      // 1: wwwroot uses the https scheme (The entire site is under https)
      // 2: login via SSL (loginhttps) (Only the login page is under https)
      if ($wwwroot['scheme'] !== 'https' && !$CFG->loginhttps)

      Unknown macro: { throw new coding_exception('Must use https address in wwwroot when ssl proxy enabled!'); }

      The problem I now have is that during my research of this issue, I've noted that skodak has repeatedly advised against this approach, (but people on the forums are continuing to do so anyway). What I haven't found is an explanation of why sslproxy in conjunction with httpslogin is unsupported and raises an exception, other than: "because we must know how user accessed the server".

      Can someone (Petr?) elaborate on why this is an issue, and why my patch above might be inappropriate.

      Lastly, in config-dist.php, I am assuming the comments have an error?
      // Enable when using external SSL appliance for performance reasons.
      // Please note that site may be accessible via https: or https:, but not both!
      // $CFG->sslproxy = true;

      "Via https or https??"

      Thanks!

      https://tracker.moodle.org/browse/MDL-28026
      https://tracker.moodle.org/browse/MDL-24332
      https://tracker.moodle.org/browse/MDL-39808
      https://tracker.moodle.org/browse/MDL-28449
      https://moodle.org/mod/forum/discuss.php?d=178327
      https://moodle.org/mod/forum/discuss.php?d=225727
      https://moodle.org/mod/forum/discuss.php?d=20795
      https://moodle.org/mod/forum/user.php?id=924141&course=5&page=1

            Unassigned Unassigned
            davidaylmer David Aylmer
            Votes:
            4 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.