AJAX talking to .js file gives 403

(Kieran@parracity) #1

Hi guys,

 

We have made a framework that allows us to list all Sports Fields (data record assets) and buttons to toggle a metadata value to say whether they are open or not.

We use Javascript to go through the list and highlight the button that matches the correct state for each Sports Field so we know what each SF is set to.

When a user clicks on the button to change the state of a SF metadata, Javascript does that too, by connecting via a Javascript API asset in matrix.

There's also a button which toggles all Sports Fields open or closed via a JS loop.

 

Now internally, this works for us with a login (non admin). But when we give the details to an external firm to use the EXACT same login and password, in FF and IE they dont get highlighted buttons (as if no javascript worked when page was loaded). In Chrome, the highlighted buttons works on load, but when they change the state of some fields, it makes no change to the actual metadata in matrix and they dont get the javascript confirmation we had put in or anything.

 

They do get 403 errors (see below) to the Javascript API asset though. This JS API asset has PUBLIC read DENIED, but the login they are using has PERMISSION granted for READ and WRITE.

 

As I said, they are using the exact same login as us, but are external and a different IP/location. Could this has anything to do with it?

 

 

coAXRHE.png
coAXRHE.png1429x731

 

Thanks in advance!

 

(Kieran@parracity) #2

Now apparently the external companies "IT team" (I have no idea what this team consists of) have looked at it and said it works once you log off and back in again. Apparently they have tested this in all browsers and all computers they have.

(Joel Porgand) #3

Now apparently the external companies "IT team" (I have no idea what this team consists of) have looked at it and said it works once you log off and back in again. Apparently they have tested this in all browsers and all computers they have.

 

 

If they had an existing session logged in with those credentials before you made group changes to the user asset that could be the issue - new group permissions won't apply until they log out & back in again.

(Anthony Barnes) #4

I'd also check to make sure you have the 'Allow IP Change' option set to Yes in system configuration. It's possible while their first request had been authenticated the subsequent requests came from a different IP (load balancers which may only affect users external to your network, caching proxies etc).

(Kieran@parracity) #5

 

If they had an existing session logged in with those credentials before you made group changes to the user asset that could be the issue - new group permissions won't apply until they log out & back in again.

Thanks JP. Havent touched their user login in weeks and it's been working fine for us with that login.

 

I'd also check to make sure you have the 'Allow IP Change' option set to Yes in system configuration. It's possible while their first request had been authenticated the subsequent requests came from a different IP (load balancers which may only affect users external to your network, caching proxies etc).

Thanks Anthony. Just checked and it is.

 

We will see how they go this week.

 

Kieran.