"Permission Denied" Error in ADL SCORM 1.2 Test Suite

Yesterday I needed to verify that an older release of my Flash-based e-learning course-shell is indeed SCORM conformant -- specifically to the old-but-widely-used SCORM 1.2 standard. This conformance test is done using the ADL SCORM 1.2 Test Suite -- a locally-run web application that simulates the run-time environment of a SCORM-compliant Learning Management System.

The Problem

When launching this SCO in the ADL Test Suite in IE7 on Windows XP SP3, a JavaScript error alerts simply "Permission denied". This error happens when the SCO first locates the test suite's SCORM 1.2 API, so the conformance test cannot even start.

Since the test suite is a local web application (using only HTML, JavaScript, and a Java Applet) local web browser security restrictions apply. Because of this, I always copy my test SCOs into a new folder within the Test Suite folder on my C drive to prevent any potential "cross-domain" (cross-local-folder) security issues. But that does not solve this problem.

I noticed something odd when opening-with Notepad the JS file in my SCO that is responsible for finding the API -- Windows opens a curious confirmation box informing me that the internet can be useful but this file could harm my computer:


This is strange, because when I create a new JS file then open-with Notepad, no such warning appears.

It turns out Windows now flags files as "obtained from the internet" or not.

The Solution

This new Windows security restriction is the cause of this "Permission Denied" error message. Internet Explorer now blocks the scripting between downloaded local files and locally-created local files, in the same fashion as its blocking of cross-site-scripting.

The solution is to modify the properties of each individual file in the SCO to remove this "downloaded-from-the-internet" flag. At the very least, do this to the containing HTML file and the JS files it uses. Click the "Unblock" button on the File Properties window:


Unfortunately there is no apparent way to "Unblock" in bulk -- you must do it on a file-by-file basis.

One More Solution

If you clicked "Unblock" on all of your files but you still get this Permission Denied error, there is one more thing to check -- especially if your SCO's HTML file is published from Flash.

Flash HTML Publish settings by default throw a special HTML comment-block at the top of the HTML file that looks like this:

<!-- saved from url=(0013)about:internet -->

If your SCO contains that comment, IE will behave the same way as the previous case by blocking the scripting between this "saved-from-the-internet" file and the test suite API. Just delete that comment block and you will be good-to-go.

Escaped Newline not properly rendering from XML

When setting a Flash TextField's text to some data that is loaded from an external XML file, I noticed the newline characters defined in my XML file, "\n", were being rendered as the string "\n" rather than an actual line-break.

The Problem

Here is a simplified example of this situation:

The XML file

<root test="Line1\nLine2\nLine3"></root>

The ActionScript

var xml:XML = new XML();

xml.load("slash-n.xml");

xml.onLoad = function()
{
   var testAttr:String = this.firstChild.attributes.test;

   trace(testAttr);
   //this traces: Line1\nLine2\nLine3

   trace("Line1\nLine2\nLine3");
   //this traces:
   //Line1
   //Line2
   //Line3

   trace(testAttr.indexOf("\\n"));
   //this traces: 5
};

This example illustrates that the first trace, using the externally-loaded string, actually outputs "\n", whereas the second trace renders the newline characters in the string literal as line-breaks.

The problem here is that the XML class actually escapes slashes it sees by doubling them up, as in "\\n". This behavior is observed in the third trace which shows that "\\n" exists in the string.

The Solution

There are two ways to solve this -- a quick way and a better way.

A Quick Solution - ActionScript Change

The quick way to solve this, leaving the XML as-is, is to simply replace "\\n" with "\n" after the XML load:

ActionScript now replaces "\\n" with "\n"

var xml:XML = new XML();

xml.load("slash-n.xml");

xml.onLoad = function()
{
   var testAttr:String = this.firstChild.attributes.test;

   testAttr = testAttr.split("\\n").join("\n");

   trace(testAttr);
   //this now traces:
   //Line1
   //Line2
   //Line3
};

This solves the problem.

But what if our attribute needs to contain other special characters such as a less-than/greater-than signs or double-quotes? Those must be escaped using the entities &lt; &gt and &quot;, and with a lot of those in the XML, this hinders readability and, if the file is being managed by hand, also hinders writability. A better way would be to use a XML CDATA block instead of an XML attribute.

A Better Solution - ActionScript and XML Changes

This solution takes advantage of the CDATA block, whose contents are not parsed during the XML load, thus not requiring us to escape less-than/greater-than signs and double-quotes.

The ActionScript XML class still doubles-up slashes so we will still need to replace "\\n" with "\n", but our XML file will have higher readability and writability.

Before: XML attribute leads to low readability/writability

<root test="&quot;Line1&quot;\n&gt;&gt;Line2\n&lt;Line3&gt;"></root>

After: XML changed for higher readability/writability

<root><![CDATA["Line1"\n>>Line2\n<Line3>]]></root>

ActionScript refers to CDATA block and replaces "\\n"

var xml:XML = new XML();

xml.load("slash-n.xml");

xml.onLoad = function()
{
   var testCdataText:String = this.firstChild.firstChild.nodeValue;

   testCdataText = testCdataText.split("\\n").join("\n");

   trace(testCdataText);
   //this traces:
   //"Line1"
   //>>Line2
   //<Line3>
};

This solves the newline problem while also increasing the readability and writability of the XML.