Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

removing X-Requested-With header to do CORS still does not work with koa #8272

Closed
sallespro opened this issue Jul 20, 2014 · 13 comments
Closed

Comments

@sallespro
Copy link

Can't seem to be able to do CORS with koa backend and $http from angular ( v1.2.12 ).

#1004

@pkozlowski-opensource
Copy link
Member

@sallespro removing X-Requested-With header in v1.2.12 won't change anything as this header is not sent by default. What you need to do is to configure your server to respond to the pre-flight CORS requests, background information here: http://www.html5rocks.com/en/tutorials/cors/

Quick google for cors, angularjs and koa brings many results and more importantly, those resources:
https://github.com/koajs/koa/wiki Among them you can find: https://github.com/evert0n/koa-cors

In any case this is more a support question about backend-configuration and not a problem with AngularJS so I'm going to close this one for now. Support questions like this are better directed to one of those channels:
https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question

Would be happy to re-open if you still believe that there is a bug in AngularJS and can provide a minimal reproduce scenario. Thnx!

@sallespro
Copy link
Author

thanks for indicating the koa-cors resources, i am currently using it in the backend.

i was surprised to see this X-Request-With issues around CORS and $http, and having attemped basically all this alternatives : setting headers manually in the request, changing $httprovider defaults at .config, changing the request at runtime with transformRequest, i do not know what to do.

The backend is responding nicely to a simple GET with ( http://requestmaker.com/ ).

what could i possibly do ?

@pkozlowski-opensource
Copy link
Member

@sallespro I would start by comparing headers sent by http://requestmaker.com/ to the ones sent by your app. But yes, you should really try to isolate your scenario (the exact HTTP request / response with headers - for now it is not even clear what is the HTTP method that is failing) and ask this question on one of the support channels.

@sallespro
Copy link
Author

hi pawel,

i have followed your instructions and look forward getting over this issue.

i have compared the headers from requestmaker and a way to replicate.

you can replicate the problem and see the error below

XMLHttpRequest cannot load http://mydomain:3000/api/posts. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3001' is therefore not allowed access

this issue #7910 called my attention too, because that is a bit of what it looks like, some herders being merged and not really working...

@lord2800
Copy link

Your server is not responding with Access-Control-Allow-Origin. The client doesn't send Access-Control-Allow-Origin--the origin itself must respond with that.

@sallespro
Copy link
Author

Hi jEFF, thanks for joining. i didn't really understand what you meant.
Indeed the $http request is not sending the Access-Control-Allow-Origin header, eventhough you can see it logged to console in the transformrequest.
my server, on the other hand, is responding nicely with to an equivalent request via http://requestmaker.com/.

@lord2800
Copy link

Yes, of course $http is not sending the header. It shouldn't be sending the header. Your server needs to be responding with the header.

@sallespro
Copy link
Author

i see, what headers should i send to make the request successfully ?

@lord2800
Copy link

At the very least, Access-Control-Allow-Origin. See: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

@sallespro
Copy link
Author

currently, the chrome browser sends this headers, which seem to be ok, except for not including the Authorization...why that happens ?

it looks like despite including in the $http request config object, the actual request does NOT include it.

OPTIONS /api/posts HTTP/1.1
Host: mydomain:3000
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://run.plnkr.co
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Access-Control-Request-Headers: accept, authorization
Accept: */*
Referer: http://run.plnkr.co/iVWDxS6CGMMP2mfU/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,pt;q=0.6

@lord2800
Copy link

You're still trying to send Access-Control-Allow-Origin from $http. That won't work. Your server needs to respond to your request with Access-Control-Allow-Origin to your client's request.

@sallespro
Copy link
Author

yes, indeed. But the server is responding fine if the client request is made by this third party site. It is NOT a problem with the server not responding accordingly.

the question is why $http request does not include the Authorization header ?

@lord2800
Copy link

Because you didn't read the rest of the article I linked you to. You need to add withCredentials to the request options, and the server needs to reply to the OPTIONS request that will be made because of that correctly. If you don't do both of those, your request will still be incorrect. Really, you should read the article I linked you to--it goes over all of this in detail with examples.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants