skip to main page content CETIS: Click here to return to the homepage
the centre for educational technology interoperability standards

skip over the long navigation bar
Press centre

Inside Cetis
what is Cetis?
Contact us
Cetis staff
Jobs at CETIS


XML: Click here to get the news as an RSS XML file XML: Click here to get the news as an Atom XML file iCAL: Click here to get the events as an iCalendar file

what are learning technology standards?
who's involved?
who's doing what?

CETIS Groups
what are cetis groups?
what difference can they make?
Assessment SIG
Educational Content SIG
Enterprise SIG
Metadata SIG
Life Long Learning Group
Portfolio SIG
Accessibility Group
Pedagogy Forum
Developer's forum

Accessibility (310)
Assessment (74)
Content (283)
Metadata (195)
Pedagogy (34)
Profile (138)
Tools (197)
For Developers (569)
For Educators (344)
For Managers (339)
For Members (584)
SCORM (118)
AICC (18)
CEN (34)
DCMI (36)
EML (47)
IEEE (79)
IMS (302)
ISO (21)
OAI (24)
OKI (20)
W3C (37)

Going back to HACP? I think not. Not secure.

Posted on November 09 2004 by Claude Ostyn in reponse to A feature or a bug; SCORM and cross domain scripting

A number of people have suggested solving this problem by going back to AICC "HACP" instead of the SCORM API. That is ignoring the security issues with that approach, unless you are willing to give up significant functionality.

If you use HACP for posting only, you can use just JavaScript. You cannot get any data from the LMS. You just call a URL with the posted data, and this can be any server; the LMS server will return some other page, but you can do this in a hidden frame and just ignore that page. For example, you can post a score but you cannot get suspend data from a previous session.

If you want to use HACP to *get* data from the LMS when the content is served by a different server, then you only have those choices:
(a) Using JavaScript only: Use Post to the LMS server and it returns a response to a frame. Since the frame is from a different server, you cannot read and parse text from that frame using JavaScript, because of browser security. This choice does not work. You can post data but not get data.
(b) Use a Java applet. You can just collect the response and parse it as you see fit and make that data available thru JavaScript. However, since you need to talk to a server other than the one that served the applet, the applet must be signed to be allowed out of the sandbox.
(c) Use an ActiveX object. Works the same as a Java Applet, must be signed in any case, grave sandbox issues.

The bottom line is that in order to use HACP for two way communication (get data as well as set) you have to compromise security at the browser level by making the user accept a signed applet from the content server.

There is another HACP security issue, which is that it exposes the LMS server to Cross-Site Posting exploits, one of the oldest Web security issues; it is possible to lock the server down, for example by securing the server to accept postings only from applets served by known remote content servers, but that may be difficult to maintain.

No, the real solution is not in cheating security at the client or browser level. If cross domain communication takes place, it should be in a managed, logged, auditable way, i.e. on the server side. In the meantime, Click2learn does ship a proprietary signed applet solution that works with any SCORM content when that content must be run from another server; something like that may be the only solution if, like many implementers of elearning, you have no control over the network infrastructure.

Replies to this post:

Creative Commons License This work is licensed under a Creative Commons License.

syndication |publisher's statement |contact us |privacy policy

 go to start of page content