This question already has answers here:
Why doesn't adding CORS headers to an OPTIONS route allow browsers to access my API?
(36 answers)
How does the 'Access-Control-Allow-Origin' header work?
(19 answers)
Closed 4 years ago.
I am deploying my first app on heroku. (It's a node.js/react app.) The app has deployed successfully, but when I try to login I get this error:
Access to XMLHttpRequest at 'https://<myApp>.herokuapp.com/users' from origin
'https://<myApp>-front-end.herokuapp.com' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check: No 'Access-
Control-Allow-Origin' header is present on the requested resource.
I know other answers explain how to fix this problem with a proxy url, but I am wondering whether I did something wrong in the first place. Following an online tutorial, I deployed the front end and back end separately, and that seems to be causing the problem. Should I have deployed the front end and back end together to avoid this problem? Or is getting around this problem a normal part of deploying an app?
Related
I'm following the docs to set up a scene via the forge API here:
http://forgetoolkit.com/#/tutorial?id=step-2-set-up-a-scene
I'm using 3 legged authentication and have tried just about every variation possible when hitting the API and I always get back 400 Bad Request.
I was told by somebody at Autodesk that objectId and bucketKey are not needed for 3 legged authentication so I have not included them here (it did not work with them).
I was able to create a scene with the ToolkitService from step #3 here: http://forgetoolkit.com/#/helloworld
I opened the network inspector while it was making the request and even copied all of the parameters from that request to the request that I was making through the API and still no avail. The API hit with ToolkitService is a different endpoint all-together from what is shown in the docs and it only accepts cookies and no authorization header.
Thanks for any help!
I have implemented an authorized action as explained in this question as well as the answer by #vdebergue.
This was working great, and the requests made by the front-end application were automatically adding an X-XSRF-TOKEN request header, with the token obtained from the login response.
However upon deploying both front-end and back-end, the requests issued from the browser are no longer adding the X-XSRF-TOKEN request header, thus causing an Unauthorized response from the server (rightfully so).
What I am failing to understand is, what is it that changed between development and deployment?
I do have the request header specified in cors.allowedHttpHeaders:
play.filters.cors.allowedHttpHeaders = ["Accept", "Origin", "Content-Type", "X-XSRF-TOKEN"]
I doubt I have to add this header manually from React (in fact the issue probably has nothing to do with the front-end).
Thanks!
Edit 1:
List of XHR requests:
Details of the login POST request, can see the X-XSRF cookie and the token being passed:
Details of the unauthorized GET that is not setting the X-XSRF as request header:
Same as previous screenshot, but running on localhost, getting authorized with the header added:
Assuming you implemented correctly, and the cookie is not attached during deployment, the issue might be related to the domain of your cookie. The way I did it is to define an an env variable and use it to hold the domain value; so it does not break the implementation during development and tests.
You can look at the Playframework API documentation for more information on how to use the cookie.
Solved in an unconventional matter: front end was made with react, which offers a way to build a static production version.
I simply integrated those static files with play framework's index.scala.html, instead of trying to run it as a separate app on a different port.
It works, however i will not mark it as a best answer yet, because i don't know whether a mobile app connecting to the same play framework backend will play along nicely when it comes to authorisation and cookies. Mobile apps are not browsers (and maybe don't abide by their limitations), and Postman had no issues with cookies.
To be checked.
Note: Solved - question makes no sense, my understanding of CORS was incorrect and lead me to ask this question.
The answer is simple as pointed out by #CBroe below - CORS needs to be configured on the game server (in the example in this qestion).
I have a Facebook WebGL game that I'm wanting to host using Facebook's simple hosting (https://developers.facebook.com/docs/games/services/contenthosting/).
Is it possible to use Facebook's Simple Hosting for a WebGL game and still contact my web server (mygamedomain.com)? Is there somewhere in the FB app config to specify domains to allow?
Is the only way to get around this to serve the game from mygamedomain.com also?
I'd really like to avoid serving the game from my webserver if possible.
Any ideas or suggestions?
Not doing so will generate an error as expected:
XMLHttpRequest cannot load https://mygamedomin.com/mygame.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://apps-1287636812638.apps.fbsbx.com' is therefore not allowed access.
Just to be clear as there seems to be some confusion:
Game is hosted by facebook using their "Simple Hosting" service, not on my own server, .
I know CORS is the solution - the question is - does Facebook allow/support this? If so where do I configure the domains to allow.
If this was on my own server I the answer is trivial - CORS. But it's not.
There are hacks to circumvent cross-origin restrictions - I'm not looking for these. There's plenty of resources already covering these.
Edit: changed the title to more accurately reflect my question.
CORS is the solution to your problem here.
This question/the answer is not Facebook specific - the issue would be the same with any other domain serving your content, that is different from your own.
Your client-side code is hosted under the Facebook domain, and tries to make a request to your domain - that is the cross-domain part. Your domain is the party that holds the power to either allow or deny this request - by default, it would be denied, but by responding with the appropriate header, your server can signal to the browser, "yes, that's ok, he [your code running under facebook.com] is one of the good guys ..."
So you need to configure this on your server, that you want to make the request to.
I have an api gateway installed that I'm trying to program against. Requests work when using apps like Postman but when I try to connect through code in the form of XMLHTTPRequests I get 401... No 'Access-Control-Allow-Origin' header is present on the requested resource. saying that the server doesn't allow cross site calls.
Maybe I'm not fully understanding how this works but it seems that apps like Postman circumvent this somehow. Whereas when I'm trying to access the api from a local file in my browser I bump into this problem.
Do I need to host the webpage I'm calling from to get this to work? Or am I missing something else here?
When the browser issues a XMLHTTPRequest, it checks if the origin (i.e. the domain) of that request is allowed by the endpoint to send requests. The check is done by a preflight request, i.e. a HTTP OPTIONS request which should provide a response containing a Access-Control-Allow-Origin header with the domain originating the request (or * to allow all domains).
Since this is a security measure of the browser, mainly based on the fact that browsing web pages the user may not know which requests are sent to which endpoints, Postman simply does not need to apply it because its requests are explicitly sent by the user himself.
https://developer.mozilla.org/en-US/docs/Glossary/CORS
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
I have a problem with RESTful service call over SSL in AngularJS application, it is a POST call.
In Chrome's inspector I can see OPTION call where column status has value Canceled and column Type has value Pending.
At a server side I get error:
default-akka.actor.default-dispatcher-7, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
If I execute a POST request from Chrome's plugin Poster it works fine. Also, it works fine if I turn off ssl and use http insteadof https.
It also works if I create html page with submit to https url.
Thanks for any idea.
Zlaja
is it trying to do a POST cross-origin?
A POST to the same origin should not result in an OPTIONS pre-flight query. So it sounds like you may be having an issue that the OPTIONS query isn't returning the correct headers.
This would also be a reason why Chrome's Poster plugin works fine because it's a plugin and specifically bypasses the usual Cross-origin security protection for debugging purposes.
Have a look at cross origin (CORS) information here:
http://www.html5rocks.com/en/tutorials/cors/