How to force the LMS to call index_lms_html5.html?

We want ONLY the HTML5 version of a particular course to load in the LMS (Cornerstone OnDemand). We are all good on how to output to HTML5 and we have tested the file locally. When we publish from Storyline 2 update 7 we get both the SWF and the HTML5 files in the output. I am guessing there are dependencies.

It seems, however, that we're going to have to do some manual editing of the manifest file and possibly some other files in the output in order to get the LMS to launch ONLY the HTML5. Before I try brutal hacks like removing the index_lms.html file or manual trial and error edits—does anyone know how to do this already?

UPDATE: One of my IDs has figured out how to work around the LMS and browser hiccups and force HTML5 to load in any compatible browser.
Not sure if this link will take you directly to his post (with screenshots) but if not, it's on page 3 of this thread. Thanks a million @BrettBerish.

https://community.articulate.com/discussions/articulate-storyline/how-to-force-the-lms-to-call-index_lms_html5-html?page=3#

Thanks to Phil, Steve, Mike and Ashley.

97 Replies
Brian Allen
Matthew Bibby
The more I think about it, the more I realise that the right call for Articulate at this stage may be to not provide a HTML5 only option.

The only reason I disagree with this is because I believe there are going to be some organizations that will want to eliminate the flash files stored on their servers and this is going to cause headaches for some developers. I would like to see it provided as a use at your own risk option.

Steve Flowers
Brian Allen
Matthew Bibby
The more I think about it, the more I realise that the right call for Articulate at this stage may be to not provide a HTML5 only option.

The only reason I disagree with this is because I believe there are going to be some organizations that will want to eliminate the flash files stored on their servers and this is going to cause headaches for some developers. I would like to see it provided as a use at your own risk option.

I'm thinking the eventual direction will likely be HTML5 primary with option for Flash-based publish. It's the way things are headed. As for server admins wanting to remove SWF's, on one hand I get it. On the other... it illustrates a misunderstanding of the threat vector. The risk is entirely on the client-side. Remove the Flash player and the vulnerability goes away. Remove clean SWF's from your server and you've done nothing to improve the situation. Maybe the line of thinking is that a hacked server could setup a vulnerability through SWF's.

The best solution is for Adobe to update the Flash player and remove all system access. Insulate FP as a media player and the problem goes away permanently.

Dave Cox

I believe that you can accomplish this with one code update in the story.html file. Line 23 in the file checks for the existence of the flash player:

if (navigator.plugins["Shockwave Flash"])
{
var arrDescription = navigator.plugins["Shockwave Flash"].description.split(" ");
var nVersion = Number(arrDescription[arrDescription.length - 2]);

g_bMinFlash = (nVersion >= 10) || isNaN(nVersion);
}
else
{
try
{
var oActiveX = new ActiveXObject("ShockwaveFlash.ShockwaveFlash.10");
if (oActiveX)
{
g_bMinFlash = true;

}

I deleted everything in the brackets and replaced it with this:

if (navigator.plugins["Shockwave Flash"])
{
g_bMinFlash = false;
}

This will cause the player to default to anything but flash.

Dave Cox

I believe that you can accomplish this with one code update in the story.html file. Line 23 in the file checks for the existence of the flash player:

if (navigator.plugins["Shockwave Flash"])
{
var arrDescription = navigator.plugins["Shockwave Flash"].description.split(" ");
var nVersion = Number(arrDescription[arrDescription.length - 2]);

g_bMinFlash = (nVersion >= 10) || isNaN(nVersion);
}
else
{
try 
{
var oActiveX = new ActiveXObject("ShockwaveFlash.ShockwaveFlash.10");
if (oActiveX)
{
g_bMinFlash = true;

}

I deleted everything in the brackets and replaced it with this:

if (navigator.plugins["Shockwave Flash"])
{
g_bMinFlash = false;
}

This will cause the player to default to anything but flash.

Aubrey Berish
Steve Flowers
Brian Allen
Matthew Bibby
The more I think about it, the more I realise that the right call for Articulate at this stage may be to not provide a HTML5 only option.

The only reason I disagree with this is because I believe there are going to be some organizations that will want to eliminate the flash files stored on their servers and this is going to cause headaches for some developers. I would like to see it provided as a use at your own risk option.

I'm thinking the eventual direction will likely be HTML5 primary with option for Flash-based publish. It's the way things are headed. As for server admins wanting to remove SWF's, on one hand I get it. On the other... it illustrates a misunderstanding of the threat vector. The risk is entirely on the client-side. Remove the Flash player and the vulnerability goes away. Remove clean SWF's from your server and you've done nothing to improve the situation. Maybe the line of thinking is that a hacked server could setup a vulnerability through SWF's.

The best solution is for Adobe to update the Flash player and remove all system access. Insulate FP as a media player and the problem goes away permanently.

Actually, there's been cross-site-scripting vulnerabilities where a safe (but published with an older Flash ver) swf file on a safe server can be used to load a malicious file from an attacker-controlled server, by passing the right arguments as part of a url. This site goes into much more detail, and as a security company we have to take scenarios like that seriously.

As heavy users of Storyline, we can have hundreds of swf files on our site. If another vulnerability like that is found, we'd have to wait for Adobe to patch Flash, possibly have to wait for Storyline to update to confirm it's output is patched, and then re-publish 100+ projects.

It just ain't practical, we need HTML5-only output.

Brian Allen

Brett, based on your expertise in this area, a couple of things that I've been curious about: what if a company removes the flash player from all computers, is there still a vulnerability in that case? Or, what if the flash-related mime types are removed from servers, would that eliminate this kind of vulnerability?

Aubrey Berish

I'm not sure about the mime type issue, that's the first I've heard mention of it. I'll ask some coworkers & our IT guys who made the push to not host swf files anymore.

Removing the Flash client entirely would definitely prevent any swf-related exploits (since of course they can't run at all), but in our situation that wasn't viable as we have a large number of partner organizations that'll access our content & LMS, as well as some courses available to the general public.

Dave Howard

The Flash Player is not the only or most concerning vector.
The swf file itself is the primary vector. Who on this thread can guarantee that malicious code cannot be executed on a resting swf by a malicious dll or a command line exploit?

Thank you,

Dave Howard
Instructional Design Supervisor
ESET North America
Read our security blog at www.welivesecurity.com

Brian Allen

Not being a security expert myself, the question I have is if an organization is phasing out Flash and wants no flash running on their servers, wouldn't removing any Flash-related mime types from the server(s) prevent any Flash from running?

If a company isn't moving away from Flash this seems like a moot point, but again, I may be speaking from ignorance...

Aubrey Berish

If one deletes every Flash-related file on the server, then yes it would stop the possibility of your content being used for an exploit. However, my concern is that the Storyline Player won't automatically "fail cleanly" over to HTML5...it'll just complain about missing files and stop working.

Steve Flowers

FTR, I don't have a problem getting rid of SWF's in principle. The media had it's time. The time is coming to a close. On the other hand...

__________ is inherently a risk because of _____________. 

This could stretch to anything if you get hyperbolic enough. Circumstances... Yes anything can be a risk but you're talking about a series of seriously unlikely events. Don't like SWF's. Alrighty. Don't have a problem with that but the series of events that you describe only happens if someone already opened the door.

Short answer - get rid of your users. Yes. That's hyperbole too.

Assess the risk and react accordingly. Many organizations are still using IE8 (shudder). Priorities...