Moodle

poor https check

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.6, 1.9, 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5, 1.9.6, 1.9.7
  • Fix Version/s: 2.0
  • Component/s: Administration
  • Labels:
    None
  • Environment:
    All
  • Database:
    Any
  • Affected Branches:
    MOODLE_16_STABLE, MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_20_STABLE

Description

In all versions of Moodle, lib/weblib.php includes a snippet like this:

if (isset($_SERVER['HTTPS'])) { $protocol = ($_SERVER['HTTPS'] == 'on') ? 'https://' : 'http://'; } else if (isset($_SERVER['SERVER_PORT'])) { # Apache2 does not export $_SERVER['HTTPS'] $protocol = ($_SERVER['SERVER_PORT'] == '443') ? 'https://' : 'http://'; } else { $protocol = 'http://'; }

This doesn't work behind an SSL accelerator (an appliance that converts https: to http. A better approach:

if (isset($_SERVER['HTTPS'])) { $protocol = 'https://'; } else if (strncmp($CFG->wwwroot, 'https', 5) == 0) { $protocol = 'https://'; } else { $protocol = 'http://'; }

Also, there are lots of snippets like str_replace('http','https', ...) that break if the host name accidentally includes 'http'. They must be str_replace('http:', 'https:', ...) at the least.

A still better approach would be to use relative URL! And the default protocol must always be derived from the $CFG->wwwroot, not from $_SERVER['HTTPS'] or the port number.

Issue Links

Activity

Hide
Martin Dougiamas added a comment -

From Petr Skoda (skodak at centrum.cz) Sunday, 30 April 2006, 04:22 PM:

I agree the checks are not optimal.

IMHO the relative links are not a good solution, because Moodle directory structure is quite complex now and you may not know exactly how to construct relative paths in libraries.

From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Sunday, 30 April 2006, 04:42 PM:

Sorry, my reference to relative URL was not accurate. I meant that <a href=http(s)://www.example.com/moodle/blah/blah.php>...</a> could always be abbreviated to <a href=/moodle/blah/blah.php>...</a>, so that http/https was irrelevant.

From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Sunday, 30 April 2006, 04:52 PM:

BTW I really had to rewrite all occurrences of str_replace('http','https', ...) to str_replace('http:','https:', ...) because my $CFG->wwwroot was https://... and the silly replace code transformed it to httpss://...

From Petr Skoda (skodak at centrum.cz) Tuesday, 16 May 2006, 06:18 AM:

I have fixed all those http: and https:, the problems were caused by unsupported configuration when both loginhttps and https:// in wwwroot were set. It should be OK now.

I guess we could safely return the same protocol in qualified_me() as defined in $CFG->wwwroot because lots of other things will break anyway if there are two different URLs for one database instance.

Of course there are also user defined server ports (!=80 // !=443), they do not work in any case and never did. The only workaround is to document it properly in doc wiki.

Any objections?

From Eloy Lafuente (stronk7 at moodle.org) Tuesday, 16 May 2006, 06:43 AM:

Not here!

From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Tuesday, 16 May 2006, 09:35 PM:

Thanks for the fix and clarification. In fact we had to set loginhttps and at the same time rewrite config.php

if (isset($_SERVER['HTTPS'])) { $CFG->wwwroot = 'https://hostname/moodle'; } else { $CFG->wwwroot = 'http://hostname/moodle'; }

because some people insist on using https everywhere. This caused the trouble.

BTW Apache 2 (at least the current versions) does export $_SERVER['HTTPS']. It is either set (to on) or not set at all.

From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Tuesday, 16 May 2006, 09:43 PM:

[OT] I think the bug tracking system has an innocent bug that converts some code to a smiley

From Petr Skoda (skodak at centrum.cz) Thursday, 18 May 2006, 03:05 PM:

this:

if (isset($_SERVER['HTTPS'])) { $CFG->wwwroot = 'https://hostname/moodle'; } else { $CFG->wwwroot = 'http://hostname/moodle'; }

breaks backup/restore and other things, sooner or later you are going to run into trouble.

From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Thursday, 18 May 2006, 03:22 PM:

> breaks backup/restore and other things, sooner or later you are going to run into trouble.

Where access from class/home is http/https respectively, what else can one do?

From Petr Skoda (skodak at centrum.cz) Thursday, 18 May 2006, 03:30 PM:

You can not use two different wwwroots for one database, that is the basic Moodle rule. May sound weird, but our dark coding magic relyes on it

From Martin Langhoff (martin at catalyst.net.nz) Thursday, 18 May 2006, 09:35 PM:

Using Apache's mod_rewrite you could work through this, but it is rather tricky. At the Moodle end, it is pretty near impossible to resolve.

From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Thursday, 18 May 2006, 10:09 PM:

I think Moodle can do it.

$CFG->wwwroot = '/moodle';

$CFG->domain = 'www.example.org'; // no protocol

The latter is only needed when switching to https in case loginhttps is set.

Of course the Moodle code must be rewritten accordingly, but the result should be much cleaner, and then Moodle can work behind SSL accelerator.

From Petr Skoda (skodak at centrum.cz) Friday, 19 May 2006, 04:17 AM:

I have tried to evaluate needed changes for proper support of SSL appliances, IMHO it would be too risky for STABLE branch.

following must work in 1.6.x:

  • httpslogin
  • https in wwwroot
  • both httpslogin and https in wwwroot at the same time - quite frequent problem

proposed new features for 1.7:

  • ssl appliance support
  • disabled http for login when httpslogin enabled

will not be fixed:

  • multiple urls in wwwroot (http and https)

Documentation and temporary patches should be placed into Wiki docs.

Show
Martin Dougiamas added a comment - From Petr Skoda (skodak at centrum.cz) Sunday, 30 April 2006, 04:22 PM: I agree the checks are not optimal. IMHO the relative links are not a good solution, because Moodle directory structure is quite complex now and you may not know exactly how to construct relative paths in libraries. From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Sunday, 30 April 2006, 04:42 PM: Sorry, my reference to relative URL was not accurate. I meant that <a href=http(s)://www.example.com/moodle/blah/blah.php>...</a> could always be abbreviated to <a href=/moodle/blah/blah.php>...</a>, so that http/https was irrelevant. From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Sunday, 30 April 2006, 04:52 PM: BTW I really had to rewrite all occurrences of str_replace('http','https', ...) to str_replace('http:','https:', ...) because my $CFG->wwwroot was https://... and the silly replace code transformed it to httpss://... From Petr Skoda (skodak at centrum.cz) Tuesday, 16 May 2006, 06:18 AM: I have fixed all those http: and https:, the problems were caused by unsupported configuration when both loginhttps and https:// in wwwroot were set. It should be OK now. I guess we could safely return the same protocol in qualified_me() as defined in $CFG->wwwroot because lots of other things will break anyway if there are two different URLs for one database instance. Of course there are also user defined server ports (!=80 // !=443), they do not work in any case and never did. The only workaround is to document it properly in doc wiki. Any objections? From Eloy Lafuente (stronk7 at moodle.org) Tuesday, 16 May 2006, 06:43 AM: Not here! From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Tuesday, 16 May 2006, 09:35 PM: Thanks for the fix and clarification. In fact we had to set loginhttps and at the same time rewrite config.php if (isset($_SERVER['HTTPS'])) { $CFG->wwwroot = 'https://hostname/moodle'; } else { $CFG->wwwroot = 'http://hostname/moodle'; } because some people insist on using https everywhere. This caused the trouble. BTW Apache 2 (at least the current versions) does export $_SERVER['HTTPS']. It is either set (to on) or not set at all. From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Tuesday, 16 May 2006, 09:43 PM: [OT] I think the bug tracking system has an innocent bug that converts some code to a smiley From Petr Skoda (skodak at centrum.cz) Thursday, 18 May 2006, 03:05 PM: this: if (isset($_SERVER['HTTPS'])) { $CFG->wwwroot = 'https://hostname/moodle'; } else { $CFG->wwwroot = 'http://hostname/moodle'; } breaks backup/restore and other things, sooner or later you are going to run into trouble. From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Thursday, 18 May 2006, 03:22 PM: > breaks backup/restore and other things, sooner or later you are going to run into trouble. Where access from class/home is http/https respectively, what else can one do? From Petr Skoda (skodak at centrum.cz) Thursday, 18 May 2006, 03:30 PM: You can not use two different wwwroots for one database, that is the basic Moodle rule. May sound weird, but our dark coding magic relyes on it From Martin Langhoff (martin at catalyst.net.nz) Thursday, 18 May 2006, 09:35 PM: Using Apache's mod_rewrite you could work through this, but it is rather tricky. At the Moodle end, it is pretty near impossible to resolve. From Haruhiko Okumura (okumura at edu.mie-u.ac.jp) Thursday, 18 May 2006, 10:09 PM: I think Moodle can do it. $CFG->wwwroot = '/moodle'; $CFG->domain = 'www.example.org'; // no protocol The latter is only needed when switching to https in case loginhttps is set. Of course the Moodle code must be rewritten accordingly, but the result should be much cleaner, and then Moodle can work behind SSL accelerator. From Petr Skoda (skodak at centrum.cz) Friday, 19 May 2006, 04:17 AM: I have tried to evaluate needed changes for proper support of SSL appliances, IMHO it would be too risky for STABLE branch. following must work in 1.6.x:
  • httpslogin
  • https in wwwroot
  • both httpslogin and https in wwwroot at the same time - quite frequent problem
proposed new features for 1.7:
  • ssl appliance support
  • disabled http for login when httpslogin enabled
will not be fixed:
  • multiple urls in wwwroot (http and https)
Documentation and temporary patches should be placed into Wiki docs.
Hide
C. Lopez added a comment -

I have a similar set-up (reverse proxy does SSL; Users use https URL; connection from proxy to moodle host is regular http) and I discovered that this has the following two undesirable effects in 1.7 Stable: 1) The blocks menu for adding blocks will not make the appropriate blocks available, with the result that you can end up deleting a block and have no option to re-add it. This is particularly bad when the block is the site administration block! 2) All the links for the documentation are broken.

The source of these two problems is that in lib/weblib.php, in the functions page_doc_link and page_id_and_class, we see this line:

$path = str_replace($CFG->httpswwwroot.'/', '', $CFG->pagepath); //Because the page could be HTTPSPAGEREQUIRED

httpswwwroot is a version of the URL that ALWAYS has https: as the scheme, apparently by definition. But as noted in this bug, pagepath only gets an https: scheme if the connection was made with SSL (i.e., if the appropriate HTTP server variable is set). AFAICT, this happens in the qualified_me() function.

There could be two fixes: one is to make the line above smarter, so that the transformation works no matter what scheme is used. The other is to modify qualified_me so that it does something like this:

if ($url['scheme'] == 'https') { $protocol = $url['scheme']."://"; } else if (isset($_SERVER['HTTPS'])) { $protocol = ($_SERVER['HTTPS'] == 'on') ? 'https://' : 'http://'; } else if (isset($_SERVER['SERVER_PORT'])) { # Apache2 does not export $_SERVER['HTTPS'] $protocol = ($_SERVER['SERVER_PORT'] == '443') ? 'https://' : 'http://'; } else { $protocol = 'http://'; }

But that has the possibility of affecting $ME and $CFG->pagepath wherever they appear. It does seem to me to be the "right" solution though, but I have no idea what the ramifications might be. Especially because elsewhere $CFG->pagepath usually seems not to have the URL scheme and domain name??? I made this change in the code I'm running on a test install, so I'll see if anything else weird happens.

Show
C. Lopez added a comment - I have a similar set-up (reverse proxy does SSL; Users use https URL; connection from proxy to moodle host is regular http) and I discovered that this has the following two undesirable effects in 1.7 Stable: 1) The blocks menu for adding blocks will not make the appropriate blocks available, with the result that you can end up deleting a block and have no option to re-add it. This is particularly bad when the block is the site administration block! 2) All the links for the documentation are broken. The source of these two problems is that in lib/weblib.php, in the functions page_doc_link and page_id_and_class, we see this line: $path = str_replace($CFG->httpswwwroot.'/', '', $CFG->pagepath); //Because the page could be HTTPSPAGEREQUIRED httpswwwroot is a version of the URL that ALWAYS has https: as the scheme, apparently by definition. But as noted in this bug, pagepath only gets an https: scheme if the connection was made with SSL (i.e., if the appropriate HTTP server variable is set). AFAICT, this happens in the qualified_me() function. There could be two fixes: one is to make the line above smarter, so that the transformation works no matter what scheme is used. The other is to modify qualified_me so that it does something like this: if ($url['scheme'] == 'https') { $protocol = $url['scheme']."://"; } else if (isset($_SERVER['HTTPS'])) { $protocol = ($_SERVER['HTTPS'] == 'on') ? 'https://' : 'http://'; } else if (isset($_SERVER['SERVER_PORT'])) { # Apache2 does not export $_SERVER['HTTPS'] $protocol = ($_SERVER['SERVER_PORT'] == '443') ? 'https://' : 'http://'; } else { $protocol = 'http://'; } But that has the possibility of affecting $ME and $CFG->pagepath wherever they appear. It does seem to me to be the "right" solution though, but I have no idea what the ramifications might be. Especially because elsewhere $CFG->pagepath usually seems not to have the URL scheme and domain name??? I made this change in the code I'm running on a test install, so I'll see if anything else weird happens.
Hide
Petr Škoda (skodak) added a comment -

Hi!

I agree there are several problems related to https with some types of setups. Unfortunately there will not be enough time to clean up the codebase and test properly before the 1.8 release which is planned for January 2007 - accessibility has higher priority.

sorry

setting target 2.0 - but I guess it will be more likely 1.9

Show
Petr Škoda (skodak) added a comment - Hi! I agree there are several problems related to https with some types of setups. Unfortunately there will not be enough time to clean up the codebase and test properly before the 1.8 release which is planned for January 2007 - accessibility has higher priority. sorry setting target 2.0 - but I guess it will be more likely 1.9
Hide
Wen Hao Chuang added a comment - - edited

Here at SFSU we are using Moodle clustering. We have one load balancer running squid, and then 3 application servers behind it. So this https is important to us for squid server. Our solution is actually pretty simple - adding a site setting under the "Site policies" for "Force https" as a checkbox, and it would be up to system administrators to check (or uncheck) this checkbox for the Moodle instance. This has been working fine for us. Here is what you need to do:

(1)
In /admin/settings/security.php

At around line 63 (above // "httpsecurity" settingpage

Add the following line:

$temp->add(new admin_setting_configcheckbox('forcehttps', 'Force https', 'Force the application to always use https://. If not enabled, the default will be http://. This is commonly used with Squid server or SSL accelerator', 0));

(2)
In /lib/weblib.php

At around line 297 at the bottom of the function qualified_me(), add:

//squid hack to make it work
if (isset($CFG->forcehttps) && $CFG->forcehttps == true) { $protocol = 'https://'; }
else { $protocol = 'http://'; }

$url_prefix = $protocol.$hostname;
return $url_prefix . me();
}


I think this would be a helpful site setting for larger sites who really need to force the site to use https. Martin do you think this could be added to core? Hope this helps...

Show
Wen Hao Chuang added a comment - - edited Here at SFSU we are using Moodle clustering. We have one load balancer running squid, and then 3 application servers behind it. So this https is important to us for squid server. Our solution is actually pretty simple - adding a site setting under the "Site policies" for "Force https" as a checkbox, and it would be up to system administrators to check (or uncheck) this checkbox for the Moodle instance. This has been working fine for us. Here is what you need to do: (1) In /admin/settings/security.php At around line 63 (above // "httpsecurity" settingpage Add the following line: $temp->add(new admin_setting_configcheckbox('forcehttps', 'Force https', 'Force the application to always use https://. If not enabled, the default will be http://. This is commonly used with Squid server or SSL accelerator', 0)); (2) In /lib/weblib.php At around line 297 at the bottom of the function qualified_me(), add: //squid hack to make it work if (isset($CFG->forcehttps) && $CFG->forcehttps == true) { $protocol = 'https://'; } else { $protocol = 'http://'; } $url_prefix = $protocol.$hostname; return $url_prefix . me(); }
I think this would be a helpful site setting for larger sites who really need to force the site to use https. Martin do you think this could be added to core? Hope this helps...
Hide
Juerg Hoerner added a comment -

Thank you Wen Hao Chuang

This works on our server moodle 1.9.7 very well and error before with an ssl https installation.

Before:
PHP Fatal error: Class name must be a valid object or a string in

/lib/pagelib.php on line 67, referer: https://www.xxx/moodle/course/view.php?id=239

blank page quiz database and chat before.

Show
Juerg Hoerner added a comment - Thank you Wen Hao Chuang This works on our server moodle 1.9.7 very well and error before with an ssl https installation. Before: PHP Fatal error: Class name must be a valid object or a string in /lib/pagelib.php on line 67, referer: https://www.xxx/moodle/course/view.php?id=239 blank page quiz database and chat before.
Hide
Helen Foster added a comment -

Just noting the forum discussion about this issue: http://moodle.org/mod/forum/discuss.php?d=145608

Show
Helen Foster added a comment - Just noting the forum discussion about this issue: http://moodle.org/mod/forum/discuss.php?d=145608
Hide
Petr Škoda (skodak) added a comment -

Should be finally solved in Moodle 2.0dev, see the $CFG->sslproxy = true; in config-dist.php
Please test and file new issues for any remaining problems.

Thank you for the report and all ideas.

Petr Skoda

Show
Petr Škoda (skodak) added a comment - Should be finally solved in Moodle 2.0dev, see the $CFG->sslproxy = true; in config-dist.php Please test and file new issues for any remaining problems. Thank you for the report and all ideas. Petr Skoda

People

Dates

  • Created:
    Updated:
    Resolved: