Setting Keys on Safari Error Message

[kamipanda]

I'm having a strange problem. One user was having issues using a plugin of mine, and we eventually managed to track down a probable cause: a Safari-specific error.

Specifically, whenever the plugin calls key.set(), it throws this error message in the console:

"XMLHttpRequest cannot load coxstudio.proboards.com/plugin/key/set due to access control checks."

This is specific to key.set() - key.set_on() works just fine, oddly enough. It's also only a recent problem, as the plugin worked for the user previously (around half a year ago). There is still key data saved from previous times their actions called key.set().

Is this a known problem? Is it something I can fix on my end? If not, is there a good workaround?

[Chris]

That would be a CORS error and not necessarily specific to Safari. Unless explicitly allowed by the server, any attempt to communicate via XHR/fetch from a different origin would generate such an error. For example, if the user attempts to generate an XHR from HTTP rather than HTTPS, that would be a different origin. If the user attempts to generate an XHR from a local file:// protocol, that would be a different origin. If the user attempts to generate an XHR from a different port, that would be a different origin...

Since it occurs with a single individual and works for everyone else, it is reasonable to ask what that specific individual is doing or not doing when the error occurs. The user could have security software or an addon that blocks the attempt. A full error message would include the file, line#, character column of the error, and a call stack showing previous calls that led up to that fatal moment. Especially with CORS, it would also include a reason in the console (never made available to javascript code for security reasons).

Please have the user copy the full error message from their console and then use that information to troubleshoot the CORS Error

[kamipanda]

Thank you for the help! When I first googled the error message, all the results seemed to be for Safari browsers, and it was the only thing I could see that was different for them vs on my end.

The troubleshooting guide seems quite thorough, so hopefully I can handle it from here.

[Chris]

Feel free to post back.

For future reference, the set_on() methods do not use XHR at all and instead piggyback on the formdata being sent when using full or quick reply, so they are not subject to CORS vetting. They are, however, still protected via the CSRF tokens associated with every Proboards form.

[kamipanda]

Ah I see, yup, that makes sense, explains the behaviour I was seeing. I'm glad to have at least narrowed down exactly where the issue is. Just wish I could actually replicate it on my end For now I just need to wait for the user to have a few spare minutes.