inherit
265444
0
Sept 6, 2024 14:50:55 GMT -8
kamipanda
18
November 2021
kamipanda
|
Post by kamipanda on Jun 11, 2024 1:52:56 GMT -8
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?
|
|
inherit
Official Code Helper
65613
0
1
May 11, 2024 14:19:23 GMT -8
Chris
"'Oops' is the sound we make when we improve"
8,943
December 2005
horace
|
Post by Chris on Jun 11, 2024 6:00:27 GMT -8
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
|
|
inherit
265444
0
Sept 6, 2024 14:50:55 GMT -8
kamipanda
18
November 2021
kamipanda
|
Post by kamipanda on Jun 11, 2024 6:17:19 GMT -8
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.
|
|
inherit
Official Code Helper
65613
0
1
May 11, 2024 14:19:23 GMT -8
Chris
"'Oops' is the sound we make when we improve"
8,943
December 2005
horace
|
Post by Chris on Jun 11, 2024 7:12:46 GMT -8
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.
|
|
inherit
265444
0
Sept 6, 2024 14:50:55 GMT -8
kamipanda
18
November 2021
kamipanda
|
Post by kamipanda on Jun 11, 2024 7:50:11 GMT -8
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 ![:P](//storage.proboards.com/forum/images/smiley/tongue.png) For now I just need to wait for the user to have a few spare minutes.
|
|