Moodle
  1. Moodle
  2. MDL-11061

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.8.2
    • Fix Version/s: 2.0
    • Component/s: Libraries
    • Labels:
      None
    • Environment:
    • Affected Branches:
      MOODLE_18_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      28647

      Description

      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.

      1. ssl_proxy_hack.patch
        2 kB
        Francois Marier
      2. weblib.patch
        2 kB
        Ivan Chavero

        Issue Links

          Activity

          Hide
          Holly Rae Bemis-Schurtz added a comment -

          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.

          Show
          Holly Rae Bemis-Schurtz added a comment - 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.
          Hide
          Tim Hunt added a comment -

          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.

          Show
          Tim Hunt added a comment - 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.
          Hide
          Tim Hunt added a comment -

          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?

          Show
          Tim Hunt added a comment - 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?
          Hide
          Holly Rae Bemis-Schurtz added a comment -

          Tim, THANKS! your advice fixed our site! We are so pleased to have your contribution.

          Show
          Holly Rae Bemis-Schurtz added a comment - Tim, THANKS! your advice fixed our site! We are so pleased to have your contribution.
          Hide
          John Jeuken added a comment -

          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

          Show
          John Jeuken added a comment - 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
          Hide
          Jason Meinzer added a comment -

          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.

          Show
          Jason Meinzer added a comment - 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.
          Hide
          Ivan Chavero added a comment -

          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

          Show
          Ivan Chavero added a comment - 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
          Hide
          Tim Hunt added a comment -

          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.

          Show
          Tim Hunt added a comment - 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.
          Hide
          Ivan Chavero added a comment -

          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

          Show
          Ivan Chavero added a comment - 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
          Hide
          Mike Street added a comment -

          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.

          Show
          Mike Street added a comment - 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.
          Hide
          Francois Marier added a comment -

          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.

          Show
          Francois Marier added a comment - 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.
          Hide
          Petr Škoda added a comment -

          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!

          Show
          Petr Škoda added a comment - 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!
          Hide
          Andrea Bicciolo added a comment -

          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

          Show
          Andrea Bicciolo added a comment - 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
          Hide
          Petr Škoda added a comment -

          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?

          Show
          Petr Škoda added a comment - 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?
          Hide
          Dan Poltawski added a comment -

          Pretty sure the regression is caused by $ME rather than $FULLME, going to fix in CVS

          Show
          Dan Poltawski added a comment - Pretty sure the regression is caused by $ME rather than $FULLME, going to fix in CVS
          Hide
          Andrea Bicciolo added a comment -

          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.

          Show
          Andrea Bicciolo added a comment - 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.
          Hide
          Andrea Bicciolo added a comment -

          Also updated to the latest CVS HEAD as of 20090107 15:05 GMT+1, no changes.

          Show
          Andrea Bicciolo added a comment - Also updated to the latest CVS HEAD as of 20090107 15:05 GMT+1, no changes.
          Hide
          Dan Poltawski added a comment -

          Fixed this in CVS - Petr - please can you review this.

          Show
          Dan Poltawski added a comment - Fixed this in CVS - Petr - please can you review this.
          Hide
          Petr Škoda added a comment -

          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.

          Show
          Petr Škoda added a comment - 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.
          Hide
          Andrea Bicciolo added a comment -

          Thanks Petr, looks ok now.

          Andrea

          Show
          Andrea Bicciolo added a comment - Thanks Petr, looks ok now. Andrea
          Hide
          Ben Frueh added a comment -

          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

          Show
          Ben Frueh added a comment - 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
          Hide
          Matt Oquist added a comment -

          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

          Show
          Matt Oquist added a comment - 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
          Hide
          Dakota Duff added a comment -

          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.

          Show
          Dakota Duff added a comment - 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.
          Hide
          Greg Lund-Chaix added a comment -

          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;

          Show
          Greg Lund-Chaix added a comment - 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;
          Hide
          David Balch added a comment -

          I know this has been fixed in 2.0, but I encountered a problem in 1.9.13 when we enabled SSL on login (about time!), and my solution may be of use for people still running 1.9.

          With SSL enabled the id attribute of the body tag on the course view page changed from id="course-view" to something like id="http:--example.com-course-view" - which broke the CSS on the page.

          With some digging I found that the code in qualified_me() uses $_SERVER['SERVER_PORT'] to determine if the protcol is http or https, but by default Apache doesn't necessarily set it to the correct value. In my case https login was over port 443, whilst everything else is http over port 80 - but Apache was reporting 443 for everything.

          Solution: in the VirtualHost section for http (80), include the directive "UseCanonicalPhysicalPort On", which makes Apache use the physical port for that request. (http://httpd.apache.org/docs/current/mod/core.html#usecanonicalphysicalport)

          HTH.

          Show
          David Balch added a comment - I know this has been fixed in 2.0, but I encountered a problem in 1.9.13 when we enabled SSL on login (about time!), and my solution may be of use for people still running 1.9. With SSL enabled the id attribute of the body tag on the course view page changed from id="course-view" to something like id="http:--example.com-course-view" - which broke the CSS on the page. With some digging I found that the code in qualified_me() uses $_SERVER ['SERVER_PORT'] to determine if the protcol is http or https, but by default Apache doesn't necessarily set it to the correct value. In my case https login was over port 443, whilst everything else is http over port 80 - but Apache was reporting 443 for everything. Solution: in the VirtualHost section for http (80), include the directive "UseCanonicalPhysicalPort On", which makes Apache use the physical port for that request. ( http://httpd.apache.org/docs/current/mod/core.html#usecanonicalphysicalport ) HTH.

            People

            • Votes:
              5 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: