You were quite right to point out the security issue in regard to the fastfileparser.
Following your remarks we have:
- Repeated the test with the most recent CVS version.
- Have found a solution to make our fastFileParser script secure.
Steps of the current system:
1. User clicks on Enter to open the SCORM course
2. SCORM player loads (player.php)
3. SCORM player loads the imsmanifest.xml file to build SCORM tree
4. SCORM player sets up API
5. SCORM player waits 2 seconds
6. SCORM player loads loadsco.php in iFrame that checks for SCO or asset to load.
7. Loadsco.php forwards itself to an asset or SCO via file.php.
8. That asset or SCO resolves all related content e.g. images throug the file.php.
9. The page is then displayed.
Steps of the solution proposed:
1. Steps 1 to 4 are performed just once, the first time any page from the package is loaded.
2. Steps 5 to 7 are replaced. The right SCO is immediately loaded in the iFrame through the fastfileparser.php
3. Fastfileparser.php is secured by the use of session variables created by loadsco.php. This is much faster than config.php
4. That asset or SCO resolves all related content e.g. images throug the fastfileparser.php
5. The page is then displayed.
Each other SCO or asset gets loaded in the iFrame without refreshing the SCORM player. This means that in our setup, steps 1 to 5 from the standard Moodle are redundant on subsequent pages.
See attachments '20080926_fastFileParser.php' and ''20080926_loadSCO.php'.
From our test results we think it is worth while to investigate this solution, although we still have the path to the data- folder and mimetypes hardcoded at this time. It would be nice to find a structual solution for this also.
One last remark: we have noticed that in the new version from CVS uploading SCORM packages is limited to 1MB. At VDAB only 5 of a total of 160 SCORM packages are smaller than 1MB. Is there a special reason for this limit?