Moodle
  1. Moodle
  2. MDL-27404

mod/scorm/apiphp returns wrong content-type header when loaded as javascript. This breaks SCORM for some users with restrictive security settings

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.9.11, 2.0.2
    • Fix Version/s: 1.9.13, 2.0.4
    • Component/s: SCORM
    • Labels:
    • Testing Instructions:
      Hide

      This is really hard to test - you must have IE 6 installed with all sorts of stupid locked down settings in place - I know IE 6 isn't officially supported in 2.0 but I've pushed the fix there anyway.

      It should be sufficient to test an existing "working" SCORM in IE 6 and make sure it still works after the patch has been applied.

      Show
      This is really hard to test - you must have IE 6 installed with all sorts of stupid locked down settings in place - I know IE 6 isn't officially supported in 2.0 but I've pushed the fix there anyway. It should be sufficient to test an existing "working" SCORM in IE 6 and make sure it still works after the patch has been applied.
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE
    • Pull Master Branch:
      master_MDL-27404
    • Rank:
      17089

      Description

      the script mod/scorm/player.php outputs the API link in the following fashion (e.g.)...

      <script type="text/javascript" src="api.php?id=624&scoid=1713&mode=normal&attempt=34"></script>

      However, api.php generates a content-type header for mimetype text/html which is wrong. It should be application/x-javascript. It's probably rarely done but it is possible to set IE security settings to block such a link which breaks SCORM.

      Looking at the code, the API wrapper doesn't really seem to be written to suit being embedded as pure javascript (e.g. require_login() and possible error messages) so I'm not sure if this is easy to fix.

        Issue Links

          Activity

          Hide
          Dan Marsden added a comment -

          interesting - I've got a couple of ideas on how we could improve this. 2.0 has a new admin level setting that forces users to enable js - we might be able to move that code further into api.php (can't remember where I put it in the first place) - this would mean that IE users with this security setting would get a nice notification of the issue and prevented access until they resolve it.

          Show
          Dan Marsden added a comment - interesting - I've got a couple of ideas on how we could improve this. 2.0 has a new admin level setting that forces users to enable js - we might be able to move that code further into api.php (can't remember where I put it in the first place) - this would mean that IE users with this security setting would get a nice notification of the issue and prevented access until they resolve it.
          Hide
          Howard Miller added a comment -

          Well, yes but.... I found the problem because of one of those all too frequent corporate users who simply set security to the max. They will not see this as a problem of their making, they see it as Moodle being broken. It's actually a blocker for them. They are also using IE6 (and 1.9.11) which I appreciate is not supported for Moodle 2 but that's an argument for another day (I hate myself for saying this but I think it was a mistake to exclude IE6 for Moodle 2 )

          Show
          Howard Miller added a comment - Well, yes but.... I found the problem because of one of those all too frequent corporate users who simply set security to the max. They will not see this as a problem of their making, they see it as Moodle being broken. It's actually a blocker for them. They are also using IE6 (and 1.9.11) which I appreciate is not supported for Moodle 2 but that's an argument for another day (I hate myself for saying this but I think it was a mistake to exclude IE6 for Moodle 2 )
          Hide
          Dan Marsden added a comment -

          it would be interesting to know if adding:
          header("Content-Type: application/x-javascript\n");

          to the top of api.php before any output made any difference - if it does that's easy to add - is that something you can test?

          Show
          Dan Marsden added a comment - it would be interesting to know if adding: header("Content-Type: application/x-javascript\n"); to the top of api.php before any output made any difference - if it does that's easy to add - is that something you can test?
          Hide
          Howard Miller added a comment -

          We've already asked the client to try it. Just waiting for the results. I'll let you know.

          Show
          Howard Miller added a comment - We've already asked the client to try it. Just waiting for the results. I'll let you know.
          Hide
          Howard Miller added a comment -

          Some updates... we tried this and it didn't make any difference. However, 'application/x-javascript' is wrong because that was never supported by IE6. We are now working though 'text/javascript' and 'application/javascript'.

          Another point though... I think the workaround for zlib.compression for IE6 could be wrong. The documentation (http://www.php.net/manual/en/zlib.configuration.php#ini.zlib.output-compression) implies that the values are '0' and '1' rather than 'on' or 'off'. It certainly seems that IE6 is getting the page with compression on regardless. We are also trying forcing it off with a '0'. I'll let you know.

          Show
          Howard Miller added a comment - Some updates... we tried this and it didn't make any difference. However, 'application/x-javascript' is wrong because that was never supported by IE6. We are now working though 'text/javascript' and 'application/javascript'. Another point though... I think the workaround for zlib.compression for IE6 could be wrong. The documentation ( http://www.php.net/manual/en/zlib.configuration.php#ini.zlib.output-compression ) implies that the values are '0' and '1' rather than 'on' or 'off'. It certainly seems that IE6 is getting the page with compression on regardless. We are also trying forcing it off with a '0'. I'll let you know.
          Hide
          Howard Miller added a comment -

          To confirm, the following three lines solve the issue for the IE6 user..

          @apache_setenv('no-gzip', 1);
          @ini_set('zlib.output_compression', 0);
          header( 'Content-Type: application/javascript' );

          there were placed immediately after the IE6 workaround.

          Show
          Howard Miller added a comment - To confirm, the following three lines solve the issue for the IE6 user.. @apache_setenv('no-gzip', 1); @ini_set('zlib.output_compression', 0); header( 'Content-Type: application/javascript' ); there were placed immediately after the IE6 workaround.
          Hide
          Dan Marsden added a comment -

          thanks Howard,

          I'm 80% sure that I put that IE 6 zlib fix in place and tested quite thoroughly at the time and found on/off worked fine
          this page:
          http://php.net/manual/en/zlib.configuration.php
          suggests to me that "on/off" and 0/1 should work.

          so... To cover all bases I'm thinking about replacing the IE6 check with this:

           
           //IE 6 Bug workaround
           if (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE 6') !== false) {
               @ini_set('zlib.output_compression', 'Off');
               @ini_set('zlib.output_compression', 0);
               @apache_setenv('no-gzip', 1);
               header( 'Content-Type: application/javascript' ); //this line only in the api.php IE 6 check.
           }
          

          are you able to confirm that the user_agent check is still working for your client? - they haven't modified that to the point that it fails have they?

          Show
          Dan Marsden added a comment - thanks Howard, I'm 80% sure that I put that IE 6 zlib fix in place and tested quite thoroughly at the time and found on/off worked fine this page: http://php.net/manual/en/zlib.configuration.php suggests to me that "on/off" and 0/1 should work. so... To cover all bases I'm thinking about replacing the IE6 check with this: //IE 6 Bug workaround if (strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE 6') !== false ) { @ini_set('zlib.output_compression', 'Off'); @ini_set('zlib.output_compression', 0); @apache_setenv('no-gzip', 1); header( 'Content-Type: application/javascript' ); // this line only in the api.php IE 6 check. } are you able to confirm that the user_agent check is still working for your client? - they haven't modified that to the point that it fails have they?
          Hide
          Dan Marsden added a comment -

          Howard - are you able to verify that user_agent check is ok?

          Show
          Dan Marsden added a comment - Howard - are you able to verify that user_agent check is ok?
          Hide
          Howard Miller added a comment -

          Hi Dan - yes, just heard back from the client. That works fine. I don't know if it's the Off changed to 0 or the different content-type that did the trick. The client wouldn't do any more experimenting once it worked

          Show
          Howard Miller added a comment - Hi Dan - yes, just heard back from the client. That works fine. I don't know if it's the Off changed to 0 or the different content-type that did the trick. The client wouldn't do any more experimenting once it worked
          Hide
          Sam Hemelryk added a comment -

          Thanks Dan this has been integrated now.

          Show
          Sam Hemelryk added a comment - Thanks Dan this has been integrated now.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Passing this based on comments from How, thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Passing this based on comments from How, thanks!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          And now this is part of the best Moodle weeklies ever, thanks!

          Closing.

          Show
          Eloy Lafuente (stronk7) added a comment - And now this is part of the best Moodle weeklies ever, thanks! Closing.
          Hide
          Alastair Munro added a comment -

          This bug fix seems to have caused a regression for one of our clients.

          The line:

          @apache_setenv('no-gzip', 1);

          Causes a 500 error in CentOS and RedHat.
          http://stackoverflow.com/questions/2664441/phps-apache-setenv-function-causes-500-internal-server-error

          As one of the comments in the stackoverflow link suggests it might be an issue with PHP being setup as a CGI-extension.

          Show
          Alastair Munro added a comment - This bug fix seems to have caused a regression for one of our clients. The line: @apache_setenv('no-gzip', 1); Causes a 500 error in CentOS and RedHat. http://stackoverflow.com/questions/2664441/phps-apache-setenv-function-causes-500-internal-server-error As one of the comments in the stackoverflow link suggests it might be an issue with PHP being setup as a CGI-extension.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: