Skip to main content

Hi All,

We are providing content for our client as XAPI modules via URLs. They work without any issue on desktop but we got multiple reports that they cannot finish their lessons on their mobile devices. I can confirm (tested) that it works with Chrome and Firefox on macOS, and it doesn’t work on Safari and on iOS (Chrome, Safari). (The lesson stuck in Activity in progress state.)

To be a little bit more technical: We are sending a finishing XAPI statement to the provided Docebo API URL. In the browsers, were it doesn’t work, we get an error when a request is sent to /tcapi/statements?statementId=XYZ Failed to load resource: Request header field User-Agent is not allowed by Access-Control-Allow-Headers.

Does someone else also experience this issue? Any ideas where to look for a solution, or if we could contact someone about the problem?

Thank you,

Roland

Hi Roland,

thank you for your post.

I received the ticket about this issue from your client and they provide me the courses which are not working, SS23 ELU LEATHER, SS23 ELU COLLECTION.

I run some test on my android phone and I had no issue but when I tried on Safari on my Mac I replicated the problem and I was not able to complete the course.

For this reason I can tell you that the problem is related to the content only which won’t work on Safari and on iOS (Chrome, Safari).

At the moment we don’t have any report about other clients with the same issue.

 


Thank you for your response,  @stefano.rotunno ,

Today I made some more investigation regarding the issue.

Seems like Safari don't allow 3rd party cookies by default, and this causes a “fake” CORS issue (?).

If I disabled the Cross-Origin restrictions in Safari’s Developer menu, I was able to complete our content. (https://stackoverflow.com/a/53736011/7610968)

I’ve read multiple articles and websites, they all write that this can be only fixed on the server side. A few of them (+similar issues): 

https://stackoverflow.com/questions/54184083/request-header-field-user-agent-is-not-allowed-by-access-control-allow-headers

https://developer.apple.com/forums/thread/654839

https://stackoverflow.com/questions/18642828/origin-origin-is-not-allowed-by-access-control-allow-origin

https://stackoverflow.com/questions/10143093/origin-is-not-allowed-by-access-control-allow-origin

Since we are using XAPI content with an external URL, on your side, you are showing our content (URL) in an iframe. But your app and ours are on different domains. When we are sending the statement to you (https://training.ecco.com/tcapi/statements?statementId=EXAMPLE), it fails.

What do you think about the issue? Do you think this can be fixed somehow on your side based on the above? Not sure if this can be fixed from our side.

Thank you,

Roland


Hello @stefano.rotunno, please can you send this to your dev team, Many thanks in advance!


This issue has been reported by, at least, another client to your support team. But they do not seem to understand yet.

We are having this issue too rigth now.

Our client cannot use XAPI content because a lot of their users are using Apple Safari on Desktop Mac or on Mobile Mac, does not matter, all Safari version are affected so far.

This is a cross-origin headers issue on your servers.
The headers are simply not set correctly according to standards and for “very picky” Safari to work.

 

Please, take any XAPI package (as long as the LRS is on a different domain).
Open it on Safari on any Mac and you’ll get the problem.

 

By looking at your headers, I could only find those, and it's not enough for Safari:

Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-Docebo-Api-Version

 

You should change the headers to this; here is a suggestion that will work (it is based on Scorm.com SCORM Cloud headers, that is how they are set and it works on Safari):

Access-Control-Allow-Headers: Content-Type,Content-Length,Authorization,If-Match,If-None-Match,User-Agent, X-Docebo-Api-Version
Access-Control-Allow-Methods: HEAD,GET,POST,PUT,DELETE
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag,Last-Modified,Cache-Control,Content-Type,Content-Length,WWW-Authenticate, X-Docebo-Api-Version


Note that: for Safari to accept Access-Control-Allow-Methods and Access-Control-Allow-Headers, the value in those headers must  not be a “*”, but shoud be an explicit value.


In other words. Safari does not like the “*” wildcard value.

But Chrome considers the default value for those headers to be the * wildcard.
Probably explaining why it works fine in Chrome.

 

Refs: 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers


Reply