I am using Chrome and in the debugger if i export my API request to curl and edit the request by removing the cookie header so that the request is made to the production API using curl from command-line without sending the cookie, it works fine and the CORS headers are returned.
The interesting thing here is that the sandbox API does not care whether i send the cookie or not, it always returns the CORS headers. The cookie is a really long string and seems to contain references to the origin used to make the original auth request.
The backend is only there for the OAuth2.0 flow and to solve the security issue of having to store my client secret in client side code which would be the only option without a backend. The result of my design is that the origin used when requesting the token from the API is different from the origin used to make the initial request to login.
The client code initiates the login and receives the redirect, the backend then requests the token, stores it and hands it to the front end (which does not store it anywhere) , the front end then uses the token to make API calls.
The backend and the front end are on the same domain but different hostname’s. The backend is node/express and won’t be sending a cookie in the request as it’s server side code operating outside of a web browser.
All of that works fine on sandbox but fails on production due to missing CORS headers, unless i remove the cookie then it works fine.
Based on this there must be a difference in the behaviour of the sandbox and production API’s with respect to CORS, can you please investigate.
Hi, Has there been any progress in this issue?
This needs to be looked at, it may well also present a security issue as i am able to change the behaviour of the production API by manipulating the cookie.
any progress on this yet?
Apologies for a late reply. We are currently investigating the issue and I’ll be back in touch when I have an update.
Firstly, please let me reiterate Anup’s apology for the delay in getting back to you.
Looking at the detail of our CORS policy, we do indeed have a slightly strange policy of only
allowing CORS requests in production if they don’t include cookies. I’ll investigate making a
change at our end so that the sandbox behaviour is consistent with production.
I’ve tried to reproduce your problem by writing a small single page JS app to perform an OAuth
exchange then fetch company data, which can be found at https://gist.github.com/ball-hayden/8e115941eff4866aacc5ec4289f04e54
I’m using the
Fetch api here, although jQuery’s
ajax or raw
XMLHttpRequests should behave in
a similar way.
The key appears to be the
credentials option (
XMLHttpRequests). Setting this
XMLHttpRequest) causes the browser to send cookies along with the CORS request.
As you have mentioned, this causes our backend to not return CORS headers.
However, I found that setting
false) results in the browser not sending
any cookies. As such our backend is happy to return CORS headers, and the API request succeeds.
I hope this helps.
I will try changing the credentials setting to ‘omit’ or ‘false’ , however during development i found that i had to add the credentials option set to ‘true’ otherwise the browser did not send the ‘authorization’ header to the FreeAgent Api (even though it is was set in code) so i was unable to authenticate.
I can’t remember if it tried setting that option to anything other than true when i added it so ill try again and see what happens. I would be surprised if the browser still sent the authorization header if i set it to omit or false.
Just to let you know, we’ve just made a few changes around this.
You should now be able to make requests to
api.freeagent.com with cookies, and receive the correct CORS headers back.
We’ve also updated the CORS configuration in the sandbox environment to match the production configuration.
I hope this helps - please do let us know if you see anything strange.