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