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.

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.

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