Inspiring

Question

Unauthenticated sources in Chrome, other browsers

Forum|Forum|8 years ago
November 1, 2017
4 replies
2606 views

So, after a recent series of updates, our online courses are rarely playing for customers. They get a blank screen with an error saying that the "sources are unauthenticated" or that some of the resources have been blocked. This is happening on Chrome almost 100% of the time and on other browsers intermittently.

Further digging brings up details that say our course files "was loaded over HTTPS, but requested an insecure resource 'http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash'. This request has been blocked; the content must be served over HTTPS."

We publish our courses in both SWF and HTML5. So I get that this is related to flash, and I understand that Chrome, among others, are doing away with support and that it is a dying thing. But what then is the solution? I have over 120 courses, and hundreds of people trying to take courses daily. I am in a little bit of panic mode.

I've seen others saying that you can try changing http to https in the htm output file. I will have to look into that. But it seems there has to be a better, more large-scale solution. I am not the most tech-savvy, so am I missing something? Does the latest Captivate version prevent this from happening? So if we re-publish our courses in the newest version, will it publish them differently so that this is not an issue? Or is it a matter of publishing as html5 only? But will they play then on desktop browsers?

I guess I am trying to understand what the point of publishing as a swf is if they don't work, and what we do to make it so our courses can play without issues. We can't professionally tell our customers to only use certain browser to click "allow unauthenticated sources."

Thanks in advance,

Arthur

unauthenticated sources

This topic has been closed for replies.

Erik Lord

Inspiring

It could be a caching issue...?

Have you tried it loading the course from somewhere other than your LMS?

SCORM Cloud account, for example?

Or just a regular webserver (no LMS). You'll get a 'can't find API' error but click past it and see the module functions without the error.

I'm not aware of any other issue that should cause that error/alert. If you're pretty confident you've done all the http/https replacements, then the error shouldn't appear...so maybe the LMS/browser thinks you're still accessing the old content (cache).

Yes, it is highly recommended you drop Flash publishing entirely - largely because browsers are, or have, dropping support for the player. If your environment requires it (i.e. users with old browsers that don't support HTML5) then SWF is still an ok option.

But the sooner you go to HTML5-only, the better for overall browser compatibility.

Erik Lord

Inspiring

Drat. There's gotta be one hiding somewhere....

Do you know how to use the Inspect tools in the browser? If you watch the web traffic when you launch the course, perhaps it'll highlight the specific calls that generate that error...?

ArthurTLeeAuthor

Inspiring

Boy, I'm at a loss. I tried inspecting the elements, but it keeps saying there is an http: link associated with the files. But I'm not seeing it.

What is everyone else doing with this issue? Has everyone abandoned flash altogether? We can publish them all as HTML5, and it works for the most part. But, of course, it functions a little differently, and I've found it to be more clunky/choppy in terms of when actually delivering the training. At the same time, since publishing to HTML5 alone, some people's computers seem to have issues tracking course progress or recognizing when quizzes have been taken. This is why I am again trying to find a SWF/HTML5 solution. But it appears I may be out of luck. I wonder what Adobe says about this? Is there a way to reach out to them directly?

Arthur

ArthurTLeeAuthor

Inspiring

Are there any updates on this issue? Changing the html files didn't seem to do the trick. And we still have hundreds of customers who are calling saying they can't play the course because Edge or Chrome, etc. are blocking the content. So we have to have them "load unsafe scripts," which doesn't come across very professional. Does the newest Captivate solve this issue by having the htm files point to https://adobe instead of http://? So if we republish all of our courses in the newest Captivate will that solve the problem? It still seems like this is a major Adobe issue that they would address since it is their default link in the code that is causing problems for everyone who is publishing courses with their software. Am I right or is this somehow an isolated issue for us?

Thanks,

Arthur

RodWard

Community Expert

Sounds like you may not have located all of the HTTP links. You need to get more information from your IT department isolating which specific links it is objecting to so that then you can find them.

The latest version of Captivate doesn't by default set all links to HTTPS. The Adobe web page where users can download and install the Flash Player is not a secured site requiring a login. So it's always going to be HTTP in the Captivate template files.

ArthurTLeeAuthor

Inspiring

We are still struggling to find all of the links in all of the files, I guess. We don't have an IT department per se, so this is really on me to locate them all. If I understand correctly, no one who is publishing their courses as SWF/HTML5 can get their courses to play on PCs without first clicking "Load Unsafe Scripts." This is very unprofessional for us to keep asking our customers to do this. We've tried publishing as just HTML5, and this works for the most part, but there are some other issues that have come up too that keep it from working properly all the time. It seems like Adobe can easily change the link in the scripts, right? Has there since been a patch or update or some fix for this issue? Or does Adobe expect its customer to simply go in and have to change all of the source files? The latter is very frustrating. Any advice or help would be appreciated.

RodWard

Community Expert

The problem here is that the URL reference to the download for Flash Player is a default link in the HTML code of the template file used to generate the HTM file whenever you publish any course content to HTM/SWF output. Captivate isn't going to know if your web server or LMS of choice is going to be using HTTPS, so the link (by default) is just a normal HTTP web address because the page on the Adobe website isn't HTTPS itself.

Up till recently, having a link to HTTP from inside content in an HTTPS environment didn't trigger any alarm bells. But many browser manufacturers have now decided this mismatch presents a security risk and are clamping down on the practice. As a result, one day your organisation (or your client's organisation) happens to update web browsers to a version that now imposes this stricter security limitation and bingo, your previously-working content is now being blocked.

You don't actually have to change the HTTP link to HTTPS after publishing each module/course (though that is one way to approach it). If this is going to be a known issue across anything you publish then you can just edit the code in the HTM template files hidden down inside the Captivate install directory, and then every time you publish anything using those templates they will automatically have the HTTPS version of the URL to the Flash Player download page on Adobe's website.

However, that doesn't resolve the issue for all of the content you currently have on your LMS (or your client's LMSs). That's going to require updates to the content, which will mean either uploading manually updated HTM files for each course module, or else republishing again from source files and uploading the entire course again. (You could also try getting your client's to relax their browser security settings, but that's not likely to be a popular solution.)

Since this issue only really affects SWF content, this would be a great time to bite the bullet and ditch SWF content and just run with HTML5.

We've been warning for some time now about browser vendors making it more and more complex and difficult to keep using Flash/SWF. This is just another example showing that End Of Life for Flash might come a lot sooner than the 2020 dateline announced by Adobe.

ArthurTLeeAuthor

Inspiring

Extremely helpful. Thanks, Rod. So if we just publish as html5, the courses will still play fine on web browsers? I was thinking that was just for mobile devices, but clearly I must be wrong about that.

Regarding changing the link in the HTM fils for the courses we've already published (as a quick fix while we republish the courses to html5), where exactly is the file? Am I basically just opening it up, changing the link and then saving that file over the old one within the zipped folder?

RodWard

Community Expert

Most web browsers nowadays are more than capable of playing HTML5 content. It wasn't always the case, and there are still some organisations that are living in the internet stone ages and insisting on using IE8 or something similar (which is not HTML5 compliant). So those people wouldn't be able to run your HTML5 content, but they should be updating their technology anyway. I don't believe it's wise to remain with SWF any longer.

However, publishing to HTML5 might not be exactly the 'quick fix' you are hoping for. You need to make sure that your course modules do not contain any SWF or AS3 elements that would not be HTML5 compliant. Take a look at this information about potential migration issues:

http://www.infosemantics.com.au/adobe-captivate/convert-swf-courses-to-html5

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded