How to force the LMS to call index_lms_html5.html?

Sep 22, 2015

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.

87 Replies

over 7 years ago09/21/16 at 1:11 pm (UTC)

Excellent, it sounds like it will be a great contribution to that thread, thanks for sharing!

over 7 years ago09/21/16 at 5:21 pm (UTC)

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.

over 7 years ago09/21/16 at 5:42 pm (UTC)

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

over 7 years ago09/21/16 at 6:27 pm (UTC)

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.

over 7 years ago09/22/16 at 5:49 pm (UTC)

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

Leslie McKerchie
Staff

over 7 years ago09/22/16 at 6:09 pm (UTC)

Hi Dave! Just wanted to mention that replying to the forums via e-mail attaches your signature. You are welcome to pop in and edit if needed.

over 7 years ago09/22/16 at 6:11 pm (UTC)

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...

over 7 years ago09/22/16 at 6:44 pm (UTC)

Short answer- just get rid of all your swf files

Thank you,

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

over 7 years ago09/22/16 at 7:00 pm (UTC)

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.

Dave Cox

over 7 years ago09/22/16 at 7:03 pm (UTC)

If you publish to html5 and make the change outlined above, then Storyline will play the html5 content.

The issue that I have with this is there is a lot that html5 won't do.

Steve Flowers

over 7 years ago09/23/16 at 1:08 am (UTC)

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...

almost 7 years ago06/28/17 at 12:36 am (UTC)

I tried this suggestion today, but it removed the ability to Print Results on the Results slide. It had been working previously. Any ideas about what's causing that? I'm new to SL and am already later delivering this project due to CSOD not storing results when resuming.