We are having a problem with storyline 2 tincan cross browser requests.
Everything works fine in firefox and chrome but in safari articulate doesn't appear to be sending a preflight request which is causing safari to deny any further requests.
This white paper provides technical information to help LMS developers implement the Tin Can API to fully support Articulate content, and this e-book, provided by scorm.com, includes technical best practices for Tin Can API developers.
To be more specific, Articulate content will report statements to the Tin Can endpoint as described under Section 7.6 of this document. To summarize, if the endpoint is http://mycompany.com/TCAPI/endpoint/, then all statements will be posted to http://mycompany.com/TCAPI/endpoint/statements?method=PUT. Any required headers will be added to the request data as form parameters delimited by “&.” The JSON content will also be encoded and passed in the parameter named "content." All statements will be reported in this way regardless of browser or platform.
If tracking issues persist, test your content at SCORM Cloud and compare the results with your LMS. SCORM Cloud is an industry-standard testing engine, and although “SCORM” is in its name, you can also use it to test Tin Can API content. If it works properly at SCORM Cloud but not in your LMS, open a support case with your LMS provider to troubleshoot the issue. However, if it also fails to track at SCORM Cloud, submit a case to Articulate.
Please let us know if you need anything else, and have a great day!
Also having this issue @Hanna Nicholas . Perhaps you were able to deliver a specific parameter through to get this to work? Curious what your solution was?
To @Justin Grenier, TinCan and the parameters are fine. When Articulate 2 came out, it sends it's requests to Safari differently. As a result, Safari does not allow CORS to work between externally hosted Articulate files and your LRS. There is, but of course, no documentation about how to resolve this, or what changes within Articulate that caused this. What's more is that, you shouldn't recommend inspecting Scorm Cloud, because Scorm Cloud doesn't even follow your implementation of Articulate Storyline by using an embed link ( the one in your referred link ). They do so by a series of javascript calls. I've been able to tear apart there code and find some ideas, but its absolutely obscured ( and likely on purpose ).
Ok the issue is this. Articulate 2 no longer sends JSON. It sends JSON but with the content-type set to XML. This causes parsing errors for the LRS. To resolve this, I just rewrite their requests ( among several other hacks I've implemented to deal with Articulate ) into a JSON and it will be able to be used by Safari.
If you can share one of those decoded PUT methods here (or privately in a Support Case), that's just the sort of thing that I can share with our team to figure out what might be going wrong.
It would also be helpful to know if you're testing this use our Flash (story.html) or HTML5 (story_html5.html) output.
Ah thanks so much for helping Justin. I attached a screenshot in my last comment with it showing that the content type is being sent as XML not as JSON as it did for Articulate 1. Does that work?
I'm not sure where your screenshot originated. My first guess was Safari Web Inspector, but my version of Web Inspector doesn't look like that, and even if it did, I'm having trouble figuring out how to identify specific PUT methods.
I just used the above recommended method on my machine and found a Content-Type identified as application/json, as shown in this screenshot:
If you could try the method I recommended (or let me know how to use your method), perhaps we can meet in the middle and figure out what's going wrong. Or, to open a dedicated Support Case, you can always do so here.
Hey Justin, ah you know what, I absolutely selected the wrong part of the screenshot. Attached is the correct one. You'll notice the `content-type` value set to 'application/xml'.
Also, lo and behold, I was able to resolve this issue, by rewriting the content-types of Articulate 2 requests to application/json . Which seems to fix it. But it should still be adjusted on Articulate 2's side.
Thanks for sharing that screenshot here and letting us know that you were able to fix it. As Justin mentioned, to investigate this further we'll want to know what tool you're using to generate the screenshot (maybe Safari web inspector? Or something else?).
Or, we'll need you to follow the directions Justin previously shared:
If you can share one of those decoded PUT methods here (or privately in a Support Case), that's just the sort of thing that I can share with our team to figure out what might be going wrong.
As sharing it with our Support team will help us to investigate it a bit further to share info with our QA/Dev teams in regards to any changes that would need to be made.
Once you've got the case open, let us know and we'll be happy to follow along!
Thanks so much for following up. Yes, I'm using Safari web inspector to derive those results. Fiddler is only for Windows, I believe so I wouldn't be able to use it. But Safari is displaying accurate results, because I can read the same environment variables from within my server so I know *without a shadow of a doubt* that Articulate 2 published files are sending JSON requests with content-type set to "application/json"
Ok - I think we'll want to take a look at your .story file to do a bit more testing so that we can share with our team. Can you send along a copy of your .story file to our Support engineers here? Please reference this thread and let me know you submitted it so that I can ensure it gets routed correctly and follow along.
Articulate Storyline 2 Update 5 is now available for download. It includes WCAG 2.0 support, several new accessibility features, better HTML5 performance, and bug fixes. Click here for details:
A lot of my clients are running into similar issues, to the point where we are advising not to publish Tin Can through Storyline if you intend to use it on a Macbook running Safari- it's not ideal.
I notice you said at the end of this post that version 5 is now released. I am wondering if you posted that here because version 5 contains a fix for the above issues?
Yes Lisa, that is why the information has been shared here. Be sure to update to the latest version and re-publish the content your users previously had difficulties with to see if it now works for them.
14 Replies
Good Afternoon Hannah, and welcome to Heroes!
This white paper provides technical information to help LMS developers implement the Tin Can API to fully support Articulate content, and this e-book, provided by scorm.com, includes technical best practices for Tin Can API developers.
To be more specific, Articulate content will report statements to the Tin Can endpoint as described under Section 7.6 of this document. To summarize, if the endpoint is http://mycompany.com/TCAPI/endpoint/, then all statements will be posted to http://mycompany.com/TCAPI/endpoint/statements?method=PUT. Any required headers will be added to the request data as form parameters delimited by “&.” The JSON content will also be encoded and passed in the parameter named "content." All statements will be reported in this way regardless of browser or platform.
If tracking issues persist, test your content at SCORM Cloud and compare the results with your LMS. SCORM Cloud is an industry-standard testing engine, and although “SCORM” is in its name, you can also use it to test Tin Can API content. If it works properly at SCORM Cloud but not in your LMS, open a support case with your LMS provider to troubleshoot the issue. However, if it also fails to track at SCORM Cloud, submit a case to Articulate.
Please let us know if you need anything else, and have a great day!
Also having this issue @Hanna Nicholas . Perhaps you were able to deliver a specific parameter through to get this to work? Curious what your solution was?
To @Justin Grenier, TinCan and the parameters are fine. When Articulate 2 came out, it sends it's requests to Safari differently. As a result, Safari does not allow CORS to work between externally hosted Articulate files and your LRS. There is, but of course, no documentation about how to resolve this, or what changes within Articulate that caused this. What's more is that, you shouldn't recommend inspecting Scorm Cloud, because Scorm Cloud doesn't even follow your implementation of Articulate Storyline by using an embed link ( the one in your referred link ). They do so by a series of javascript calls. I've been able to tear apart there code and find some ideas, but its absolutely obscured ( and likely on purpose ).
I'll post my findings here as I discover them.
Ok the issue is this. Articulate 2 no longer sends JSON. It sends JSON but with the content-type set to XML. This causes parsing errors for the LRS. To resolve this, I just rewrite their requests ( among several other hacks I've implemented to deal with Articulate ) into a JSON and it will be able to be used by Safari.
Thanks for this information, Trip.
If you download Fiddler and connect it to Safari, you should be able to take a look at one of our PUT methods and decode it for readability. This should demonstrate the Content-Type and the content that we are sending.
If you can share one of those decoded PUT methods here (or privately in a Support Case), that's just the sort of thing that I can share with our team to figure out what might be going wrong.
It would also be helpful to know if you're testing this use our Flash (story.html) or HTML5 (story_html5.html) output.
Thanks again for your help!
Ah thanks so much for helping Justin. I attached a screenshot in my last comment with it showing that the content type is being sent as XML not as JSON as it did for Articulate 1. Does that work?
Hello again, Trip.
I'm not sure where your screenshot originated. My first guess was Safari Web Inspector, but my version of Web Inspector doesn't look like that, and even if it did, I'm having trouble figuring out how to identify specific PUT methods.
I just used the above recommended method on my machine and found a Content-Type identified as application/json, as shown in this screenshot:
If you could try the method I recommended (or let me know how to use your method), perhaps we can meet in the middle and figure out what's going wrong. Or, to open a dedicated Support Case, you can always do so here.
Thanks!
Hey Justin, ah you know what, I absolutely selected the wrong part of the screenshot. Attached is the correct one. You'll notice the `content-type` value set to 'application/xml'.
Also, lo and behold, I was able to resolve this issue, by rewriting the content-types of Articulate 2 requests to application/json . Which seems to fix it. But it should still be adjusted on Articulate 2's side.
Hi Trip,
Thanks for sharing that screenshot here and letting us know that you were able to fix it. As Justin mentioned, to investigate this further we'll want to know what tool you're using to generate the screenshot (maybe Safari web inspector? Or something else?).
Or, we'll need you to follow the directions Justin previously shared:
If you download Fiddler and connect it to Safari, you should be able to take a look at one of our PUT methods and decode it for readability. This should demonstrate the Content-Type and the content that we are sending.
If you can share one of those decoded PUT methods here (or privately in a Support Case), that's just the sort of thing that I can share with our team to figure out what might be going wrong.
As sharing it with our Support team will help us to investigate it a bit further to share info with our QA/Dev teams in regards to any changes that would need to be made.
Once you've got the case open, let us know and we'll be happy to follow along!
Hey Ashley,
Thanks so much for following up. Yes, I'm using Safari web inspector to derive those results. Fiddler is only for Windows, I believe so I wouldn't be able to use it. But Safari is displaying accurate results, because I can read the same environment variables from within my server so I know *without a shadow of a doubt* that Articulate 2 published files are sending JSON requests with content-type set to "application/json"
Hi Tripp,
Ok - I think we'll want to take a look at your .story file to do a bit more testing so that we can share with our team. Can you send along a copy of your .story file to our Support engineers here? Please reference this thread and let me know you submitted it so that I can ensure it gets routed correctly and follow along.
Hi All!
Articulate Storyline 2 Update 5 is now available for download. It includes WCAG 2.0 support, several new accessibility features, better HTML5 performance, and bug fixes. Click here for details:
Hi Emily,
A lot of my clients are running into similar issues, to the point where we are advising not to publish Tin Can through Storyline if you intend to use it on a Macbook running Safari- it's not ideal.
I notice you said at the end of this post that version 5 is now released. I am wondering if you posted that here because version 5 contains a fix for the above issues?
Looking forward to your reply.
Yes Lisa, that is why the information has been shared here. Be sure to update to the latest version and re-publish the content your users previously had difficulties with to see if it now works for them.
This discussion is closed. You can start a new discussion or contact Articulate Support.