Ok, SharePoint is chaos. We all know it, we just don’t talk about it too much.
If you run into this issue, it means that SharePoint is responding to your request for a .js file with HTTP code 302, and providing the redirect location as the “Access Denied” .aspx page (or potentially another page). Try deleting and re-uploading the affected file first before checking anything else. If it were truly an access denied error you should be receiving HTTP code 401 (unauthorised).
Story time!
A colleague was losing their mind recently when a .js script would execute for an admin account but not for a test account. On the surface it appeared to be a standard developer issue as everything always works for the admin account!
Well, we sat down and went through the basics first.
What browsers are affected? All of them.
Ok, What users are actually affected? A random collection of them, some with identical permissions.
The fuck. Ok, let’s check the permission set up. Does our test account, and other affected accounts, have at least Read access to the file? Yes. Everyone has Read access to the file.
Ok, this is odd. Time to break out the dev tools. What does the network request look like? HTTP 302 Found, Location = …/_layouts/15/AccessDenied.aspx?…
The light slowly faded from our eyes. This was highly unusual. It was time to do a sanity check.
- We cleared all caches and tried again. Same result.
- We cleared and reset permissions on the item. Same result.
- We deleted and re-uploaded the file. It worked!
Unfortunately we have no concrete idea on what was actually happening, but at least we fixed whatever was wrong. If you have any idea please let me know down below!
Davehax | Code 