I am experiencing an issue on Cordova iOS (testing with v12.1, but multiple users have reported the issue).
I’m using Three JS in my app and while loading a texture I get a 403 Forbidden only on iOS Cordova. On Android and web (chrome, safari, firefox tested) there are no issues. The image is located in my public folder, this is the exact error:
I believe under the hood three js is using an XMLHTTPRequest to fetch the image. As far as I understood the cordova local web server should be a ‘safe origin’ to request resources from right? If I load the png in an <img /> in the DOM all is well and the image is loaded correctly.
Hey @arcnon, I know you posted this a couple years ago, but I just found it in a search. Been having the same issue with my Cordova app, which is using the fetch api to load audio files from Meteor’s public for the Web Audio API. For me, it’s a rare, sporadic error – I myself haven’t been able to reproduce it, but folks will randomly write me complaining that the audio won’t load, and Sentry tells me it’s because of these 403 Forbidden errors.
Did you ever figure out why this was happening in your app?
The permissions on the file cause it to be 403 run chmod 0755 and ensure your web user is the owner and you’ll be good to go this will ensure perms on the file are read and execute from anyone but not write
That’s not it. The 403 errors are coming from the local web server running within Cordova on the user’s device. Also it works for most users, including myself… only a fraction of users have the issue.
403 means forbidden so check the logs to see if there is anything about that request, just keep trying with your client opening and trailing logs. Also check the headers being sent on the bugged user and compare to one that’s working and see if you can see what is causing it, you may need to add debugging output to see all errors and responses to debug. It will be something with permissions
Since the server in question is not the main web server but Meteor’s WebAppLocalServer server running on the user’s device, and I can’t recreate this on any of my own iOS devices, it’s tricky to tail logs in this case. And the fetch() call in question is a single line that does work most of the time, so I’m all but positive the issue is on the server side (which is unfortunately more opaque to me), versus the client side. I’ll keep digging.