Solving the Challenge of the Cross Domain Restriction in SCORM

We have talked before about the essentials that make SCORM work. One of those essentials is the use of JavaScript. And that is part of the issue, JavaScript is not designed by nature to work cross domain.

What Does Cross Domain Mean?

Solving the Cross Domain dilemma means filling in the missing linkFirst, let’s start by understanding what a domain is. In computer network terms (according to computerhope.com), a domain is a group of resources assigned to a specific entity.  Usually the grouping is on a specific server and assigned an location identifier. In the case of the Internet or a web server, an IP address is assigned as the location identifier. To make it more memorable for those of us who don’t do numbers, we assign a domain name to an IP address. So jcasolutions.com is a domain name for the IP address 45.33.87.150.

Your LMS is installed on your webserver on your network and that network is a domain. For security, we try to keep things within the domain, which means we also can keep things out of the domain. If we didn’t, it would be too easy for someone to crack in there and do some damage, take over systems, or steal secrets. That’s why JavaScript is limited to access information only within the domain it resides; to prevent someone using code to break in.

Cross domain then is exactly as the name suggests – the ability to access or exchange information across domains.

Why Worry About Cross Domain SCORM?

If all this is for our protection, why would we want to break it? What could possibly make us want to access information cross domain? Well, here are a few possible reasons.

  1. If you have a content server with proprietary content and you need to keep it there but at the same time you need to serve it up on other domain servers.
  2. You have content that changes frequently. It would be a real pain you know where to have to re-distribute new content packages after each change.
  3. When there is third-party content you want to provide within your LMS but must remain on the vendor’s server.
  4. Ultimate control over your content, especially if you license it out.

Overview of How It Works

For this example, let’s call the two servers Client LMS and Content Server. The Content Server holds the SCORM course package and the Client LMS holds the learner information and student records in its database.

When a learner launches a course from your LMS, it is actually residing on the content server. Remember, all the javascript that communicates for recordkeeping is on that content server.

The learner exits the course and wants to bookmark where they left off. Normally this request would be blocked by the browser because of those cross domain security rules.

Breaking Through the Cross Domain

ADL logoThe simplest and obvious solution is to locate everything on one domain. Let’s assume for the moment that it’s not possible to do that. What are some alternatives? According to a whitepaper from Advanced Distributed Learning, here are just a few of the possibilities.

Simple But Dangerous

The next simplest way to resolve this is to set every browser to accept and play content no matter where it is from. That is also the absolute worst thing you could do. It’s the equivalent of opening the front door to your house and screaming out that you have cash and diamonds in the living room and you are going for a walk.

SCO Fetcher

Another possibility is to use a solution called a SCO-Fetcher. This solution was originally proposed by Albert Ip and Dr. Enrico Canale. In simple terms, you add a modification to the LMS that looks at the URL of a SCO the learner attempts to launch. If that URL is outside of the LMS’ domain, the fetcher adds the URL as a parameter of the launch. Essentially it pretends that the URL is local instead of on another domain. It does require modifying the LMS, which could be undesirable. It also could potentially cause some performance issues.

Proxy

If you set up a “virtual server” you can cause the browser to think that the content server and the LMS are residing in the same domain, even if they aren’t. This solution was proposed originally by the late Claude Ostyn. We won’t go into the details here but in many cases it can be fairly simple to implement. Its downside is that it can be complicated by firewalls and other security measures. Like the other solutions, it can impact performance at runtime as well.

Our Solution

JCA Solutions also has created an implementation called SCORM 4 Cross Domain. It essentially works like this: Place a “stub file” on the Client LMS. This “stub file” contains a SCO start file with a single hyperlink which links to a URL on the Content Server. This URL will contain information about the course to be launched as well as information about the student and maybe the session. Once the Content Server receives the request to launch a course it calls back to the Client LMS and tells it that the session has started. Then the “stub file” issues an Initialize command to the Content Server. This way the Content Server knows it has a connection and a course.

Conquering the cross domain can be a challenge, but thanks to the work of many there are a variety of solutions. The real trick becomes finding the one that works best for you.

Need help figuring out the best solution for you? Contact the SCORM Experts at JCA Solutions (support@jcasolutions.com) today.

 

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pinterest
Pinterest
Leave a reply

Your email address will not be published. Required fields are marked *