Issue Details (XML | Word | Printable)

Key: MDL-11061
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Petr Skoda
Reporter: Patrick Fitchie
Votes: 5
Watchers: 15
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

SSL Publishing a Moodle site with ISA Server and no SSL Bridging (Browser--ssl--> ISA Server --nonssl --> Moodle) breaks Quiz View

Created: 30/Aug/07 05:19 AM   Updated: 08/Aug/09 05:37 AM
Return to search
Component/s: Lib
Affects Version/s: 1.8.2
Fix Version/s: 2.0

File Attachments: 1. Text File ssl_proxy_hack.patch (2 kB)
2. Text File weblib.patch (2 kB)

Environment:
Moodle Server --> Windows 2003 running latest XAMPP moodle 1.8.2+ package
ISA Server --> Windows 2003 R2 running ISA Server 2006

ISA Server acting as a reverse proxy from the internet to the internal moodle server
ISA Server connecting with clients using SSL
ISA Server connecting with moodle server not using SSL
Issue Links:
Duplicate
 
Relates
 

Participants: Andrea Bicciolo, Ben Frueh, Dakota Duff, Dan Poltawski, Francois Marier, Greg Lund-Chaix, Holly Rae Bemis-Schurtz, Ivan Chavero, Jason Meinzer, John Jeuken, Matt Oquist, Mike Street, Patrick Fitchie, Petr Skoda and Tim Hunt
Security Level: None
Resolved date: 07/Jan/09
Affected Branches: MOODLE_18_STABLE
Fixed Branches: MOODLE_20_STABLE


 Description  « Hide
I'll try to describe my config as best as possible.

-When a browser connects to https://my.org/moodle ISA Server retreives pages from the internal site known to it as http://my.org/moodle
-cfg$-->wwwroot =https://my.org/moodle
-Moodle in general works great under this configuration
-You can create quizzes and add questions, however once questions are added and you try to preview the quiz you receive the following error:

/* begin error */
Page class mapping requested for unknown type: http:--webmail.brsd.ab.ca-moodle-mod-quiz-view line 100 of lib\pagelib.php:

call to debugging() line 65 of lib\pagelib.php:
call to page_map_class() line 50 of lib\pagelib.php:
call to page_create_object() line 51 of mod\quiz\view.php:
call to page_create_instance()

Notice: Undefined index: http:--webmail.brsd.ab.ca-moodle-mod-quiz-view in C:\moodle\wwwroot\moodle\lib\pagelib.php on line 103
Notice: Undefined index: http:--webmail.brsd.ab.ca-moodle-mod-quiz-view in C:\moodle\wwwroot\moodle\lib\pagelib.php on line 104

Page class mapping for id "http:--webmail.brsd.ab.ca-moodle-mod-quiz-view" exists but class "" is not defined line 104 of lib\pagelib.php:

call to debugging() line 65 of lib\pagelib.php:
call to page_map_class() line 50 of lib\pagelib.php:
call to page_create_object() line 51 of mod\quiz\view.php:
call to page_create_instance()

Notice: Undefined index: http:--webmail.brsd.ab.ca-moodle-mod-quiz-view in C:\moodle\wwwroot\moodle\lib\pagelib.php on line 107

Fatal error: Class name must be a valid object or a string in C:\moodle\wwwroot\moodle\lib\pagelib.php on line 67

/* end error */

Workarounds:
1. Disable ISA SSL connection for the external https://my.org/moodle (not desirably since we want all traffic encrypted) and change cfg$-->wwwroot=http://my.org/moodle
2. Enable SSL Bridging in ISA so that ISA retreives https://my.org/moodle (not desirable as is puts ssl load on moodle server), this is a little more difficult because you need to export the ssl cert from apache and then import it into the Trusted Certificate Store on the ISA Server. this can be done by using the following command: bin/openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 (of course adjusting the command line to point to correct paths of the files.

The problem I beleive lies in the pagelib.php as it does not seems to be construting the pagetype correctly for quiz view in this environment but it does appear to do it properly for other pagetypes since I can not reproduce the problem in any other module.

 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Holly Rae Bemis-Schurtz added a comment - 29/Sep/07 03:45 AM
I too am experiencing this same error message, however it is only affecting the chat and database modules.

This is what I see:
Page class mapping requested for unknown type: http:--reta.nmsu.edu:16080-moodle-mod-data-view
line 100 of lib/pagelib.php: call to debugging()
line 65 of lib/pagelib.php: call to page_map_class()
line 50 of lib/pagelib.php: call to page_create_object()
line 146 of mod/data/view.php: call to page_create_instance()

Notice: Undefined index: http:--reta.nmsu.edu:16080-moodle-mod-data-view in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 103

Notice: Undefined index: http:--reta.nmsu.edu:16080-moodle-mod-data-view in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 104

Page class mapping for id "http:--reta.nmsu.edu:16080-moodle-mod-data-view" exists but class "" is not defined
line 104 of lib/pagelib.php: call to debugging()
line 65 of lib/pagelib.php: call to page_map_class()
line 50 of lib/pagelib.php: call to page_create_object()
line 146 of mod/data/view.php: call to page_create_instance()

Notice: Undefined index: http:--reta.nmsu.edu:16080-moodle-mod-data-view in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 107

Fatal error: Class name must be a valid object or a string in /Library/WebServer/Documents/reta/moodle/lib/pagelib.php on line 67

I am not running SSL so I am not able to use that work around.

If anyone finds a fix, please advise.


Tim Hunt added a comment - 29/Sep/07 11:03 PM
This is an issue with pagelib. It happens when $CFG->wwwroot does not match what is in one of the $_SERVER variables, if I remember what we found out when I helped someone diagnose this in the forums ages ago.

Tim Hunt added a comment - 18/Oct/07 04:18 AM
The problem is that the function page_id_and_class in lib/weblib.php assumes that the global $ME, which is the URL of the current page as the web server tells us, start with $CFG->httpswwwroot.

This assumption is false in two situations:

1. The person writing config.php accidentally added a '/' at the end of $CFG->wwwroot, despite the comment in config-dist.php.

2. The sort of situation described in this bug, where there are good technical reasons why $CFG->wwwroot is different from the URLs the moodle server acutally serves.

In this case, probably the best place to fix moodle is in the qualified_me function from lib/weblib.php, so that $ME,
does always start with lib/weblib.php. However, I am not sure of the best way to do this.

If you are experiencing this problem, and you can't fix it just by editing $CFG->wwwroot, then you can probably fix it by editing qualified_me. There is now a TODO comment in there, which mentions this bug id (MDL-11061), it's about line 270, so you should be able to find the bit to edit.

To improve the situation for now, I have added two admin notifications, that are displayed if the situations 1. or 2. above are detected, with a link here. I have added them to 1.9 and HEAD, do we want them backported further?


Holly Rae Bemis-Schurtz added a comment - 23/Oct/07 03:45 AM
Tim, THANKS! your advice fixed our site! We are so pleased to have your contribution.

John Jeuken added a comment - 12/Nov/07 11:11 PM
Hi Tim,

We have the same issue and are wondering how to edit the qualified_me function so that $CFG->wwwroot matches $_SERVER?

We are running 1.7.1+
Apache/2.2.4 (Unix) PHP/5.2.3
mysql 5.0.41
SSL


Jason Meinzer added a comment - 18/Jul/08 06:41 AM
What is the point of having to set $CFG->wwwroot and having qualified_me()? The qualified_me() function will always return the wrong URL if Moodle is behind a reverse proxy, load balancer, or SSL terminating proxy. Usually having a configuration variable for an application's base URL is so that you can avoid doing things like qualified_me(), which can't account for a lot of relatively common environments. I have been able to fix all my problems where Moodle redirects to the wrong URL by replacing my qualified_me() function with this:

function qualified_me() {
global $CFG;
return $CFG->wwwroot;
}

Of course, Moodle still tells me "You have defined $CFG->wwwroot incorrectly in your config.php file. It does not match the URL you are using to access this page. Please correct it, or you will experience strange bugs like MDL-11061." which is just flat-out wrong.


Ivan Chavero added a comment - 13/Aug/08 06:51 AM
Checked the qualified_me function and it was really confusing i think that in order to eliminate the extrange behaviour of moodle when it is behind a https reverse proxy you have to refactor it to something like this:

function qualified_me() {
global $CFG;
return $CFG->wwwroot . me();
}

so i created a patch that modifies lib/weblib.php for the Moodle 1.9.2+ (Build: 20080730)

I don't really understand why qualified_me integrates the url prefix from within the server variables adding some complexity along the way when you have defined $CFG->wwwroot in config.php

to apply this little patch:

cd moodle/lib

patch -u weblib.php < weblib.patch

i hope this is useful


Tim Hunt added a comment - 13/Aug/08 12:12 PM
I think that this patch (weblib.patch) is the right sort of general approach. However, I am worried that it will not work if, for example, $CFG->wwwroot = 'http://example.com/moodle' - that is, with a path after the server name. Won't me() also contain the /moodle bit?

I acutally think a better long term solution is to completely remove me() and qualified_me() from the code-base (or at least move it to depricatedlib.php). I don't think it is necessary, and I think it is not used in many places anyway.


Ivan Chavero added a comment - 14/Aug/08 12:14 AM
I think you're right, i'm not very experienced on moodle's code but is evident that this function does not make sense it should be removed because it causes more problems that the ones is supposed to solve (whichever they are).
Eventualy most moodle installations are goingo to escale from a single server to some sort of load balancing/failover scheme that is going to be affected by this function.

It should not be very hard to do.

being simplistic:

$ grep -ri 'qualified_me()' * | grep -v function | wc -l
33

only 33 appereances on the whole code base


Mike Street added a comment - 21/Aug/08 12:06 AM
Just wanted to say that as of the latest version of 1.9.x for August 20, 2008, this is still an issue. The 'Affects Versions' part of this bug should reflect this.

This has been a showstopper for us, unfortunately. It has brought an entire summer's worth of work to a halt for us. I'm about to try the patch now, and I sincerely hope that someone can remove this function quickly.


Francois Marier added a comment - 23/Sep/08 12:35 PM
I've attached a hack that should work for all sites. However, it's a hack because it forces you to add one more variable to your config.php: wwwserver

For example:
$CFG->wwwroot = 'https://example.com/moodle';
$CFG->wwwserver = 'https://example.com';

This is not meant to fix the issue in Moodle, it's just there to fix the immediate issue for people who are running into this problem. It still needs to be fixed properly in Moodle.


Petr Skoda added a comment - 06/Jan/09 06:39 AM
I have committed several changes, it should be now possible to use external SSL - the only problem here is that you can not use both http: and https: at the same time - see http://docs.moodle.org/en/masquerading

The setting can be enabled only in config.php, see config-dist,php

thanks for the report, please test 2.0dev and reopen if needed!


Andrea Bicciolo added a comment - 07/Jan/09 08:45 PM
The message

"You have defined $CFG->wwwroot incorrectly in your config.php file. It does not match the URL you are using to access this page. Please correct it, or you will experience strange bugs like MDL-11061."

now appears on Linux setup of Moodle 2.0 with no apparent reasons. The config.php is visually correct and updted to latest config-dist.php, and Moodle works correctly.

Andrea


Petr Skoda added a comment - 07/Jan/09 09:07 PM
What exactly is in your $CFG->wwwroot and what address did you use to access moodle?
It might be also caused by MDL-17802, could you please try to update?

Dan Poltawski added a comment - 07/Jan/09 11:03 PM
Pretty sure the regression is caused by $ME rather than $FULLME, going to fix in CVS

Andrea Bicciolo added a comment - 07/Jan/09 11:05 PM
Petr,

wwwroot is http://servername/moodle20 (no SSL at all)

and the server is accessed using http://servername/moodle20

No proxies are between servers and clients.


Andrea Bicciolo added a comment - 07/Jan/09 11:06 PM
Also updated to the latest CVS HEAD as of 20090107 15:05 GMT+1, no changes.

Dan Poltawski added a comment - 07/Jan/09 11:09 PM
Fixed this in CVS - Petr - please can you review this.

Petr Skoda added a comment - 08/Jan/09 12:32 AM
big thanks!
I overlooked these www tests on admin/index.php - I have removed them - the new code in lib/setuplib.php should be much more reliable.

Andrea Bicciolo added a comment - 08/Jan/09 01:40 AM
Thanks Petr, looks ok now.

Andrea


Ben Frueh added a comment - 12/Mar/09 02:07 AM
I just want to thank Francois for saving my a** with this issue on Moodle 1.9.3+. We implemented full SSL, then no quizzes, then people freaking out, then Ben learning how to apply patches for the first time Thanks!

Ben Frueh


Matt Oquist added a comment - 06/Jul/09 04:33 AM
I'm experiencing this again, after an upgrade from 1.8.3+ to 1.9.5+. I've got Apache2 (httpd-2.0.52-38.ent.2), php-5.2.9-1.rs.el4, and RHEL4, and $_SERVER['SERVER_PORT'] is 80 even though I'm clearly connecting via https (and http connections are rewritten by Apache to be https).

I'm planning to just hack around this the same way I did in 1.8.3 - I'll set $protocol = 'https://' toward the end of qualified_me().

I see this is fixed in 2.0 - great.

Cheers,
Matt


Dakota Duff added a comment - 16/Jul/09 01:14 PM
For anyone still interested, I was able to get around this issue simply by auto prepending the following php code:

<?php
$_SERVER['SERVER_PORT'] = 443;
?>

Just added that, and changed $CFG->wwwroot to https:// and we were good to go.


Greg Lund-Chaix added a comment - 08/Aug/09 05:37 AM
I've run into this issue running 1.9.5 behind a Varnish proxy as well. I've found that adding the following to config.php immediately after setting $CFG->wwwroot seems to work:

$_SERVER[SERVER_PORT] = 80;