AngularJS and Laravel - crossdomain CORS / XHR requests lacking (remember_) cookies - cookies

My CORS / XHR requests lacking the remember_xyz cookie in the request headers when i don't use the --disable-web-security option in chrome. If i enable that option the remember_xyz cookie will be included in the request headers and everything is working fine.
As workaround i'm currently sending the auth credentials via basic auth header. But i think that's not the intended or right way.
How can i get that remember cookie included in the request headers?
Edit:
In chrome's network console i can see the following:
(without --disable-web-security option in chrome)
The remember cookie is sent by laravel in the first response headers. But is not included in the next request's headers by angular. Why?
Every request has that OPTIONS preflight request before the actual request fires. Is it possible that the preflight request removes/breaks the cookie somehow?
(with --disable-web-security option in chrome)
The remember cookie is sent by laravel in the first response headers and will be sent in the next request's headers by angular. Everything is fine.
Edit 2:
Is it up to me to include the said cookie out of the response headers into the request headers? When yes, why i don't have to do this with "--disable-web-security" option enabled in chrome?
What i'm doing wrong?
Thank you!

Not sure I'm answering your question directly, but I'll take a stab. You DO need to set certain headers on the client side AND server for CORS.
The client needs to know to send the Cookie headers, or it will strip them out. For jQuery, this means setting the withCredentials parameter in your ajax call. See more info here. This sounds like the issue you are grappling with.
On the server side, you may need to ensure pre-flight requests are setup.
For instance, when I used CORS in Laravel 4, I had a filter to add some headers to each response:
App::after(function($request, $response)
{
// Note that you cannot use wildcard domains when doing CORS with Authorization!
$response->headers->set('Access-Control-Allow-Origin', 'http://dev.domain.local');
$response->headers->set('Access-Control-Allow-Credentials', 'true');
$response->headers->set('Access-Control-Allow-Headers', 'Authorization, X-Requested-With');
});
Within a controller, I also had an OPTIONS request respond for pre-flight requests. An example of that is:
public function optionsComplex()
{
$response = Response::make(null, 200);
$response->headers->set('Allow', 'GET, PUT, DELETE');
$response->headers->set('Access-Control-Allow-Methods', 'GET, PUT, DELETE');
return $response;
}
Hope that helps.

Related

Why cookies appear in request header but not response header when visiting a new website?

This is a incognito window in chrome visiting oracle. Please notice that the request header already has cookie in the very request.
I also tried to use GuzzleHttp in php and postman. I can't get the cookie from anywhere.
Actually I am trying to crawl some other website, and that website has the same problem. I can't get the cookie so I got rejected.
Isn't cookie something that the server returns to the browser? Why in this case it is like the browse know the cookie in the first?
Http cookies are set once in a response by the server (with a Set-Cookie header), then they are included by the browser in each applicable subsequent request.
So it is perfectly normal that cookies your browser already obtained are present in the request but not in the response.
Cookies may also be set on browser side by Javascript, but that also can't happen before the first request (to at least retrieve that Javascript).

send a cookie with XMLHTTPRequest (TVMLJS)

I am developing an application for my AppleTV. The App will read movies from an online website that hasn't developed any API for this kind of thing.
I use XMLHTTPRequest to get the different URLs and have the user search for his movie, etc... Everything is working fine, except for a single request. To get the movie URL, I have to send a get request to a specific address (let's say http://example.com/getmovie.html) with a constant cookie (let's say mycookie=cookie).
I've tried using setRequestHeader:
var xhr = new XMLHttpRequest();
xhr.open("GET", url, false);
xhr.withCredentials = true;
xhr.setRequestHeader('Cookie', 'mycookie=cookie');
xhr.send();
But no cookie seems to be sent.
I also tried setting the cookie with Document.cookie like I would have probably done in a "normal" js script (running in my browser) but no luck either.
This is extremely frustrating, especially since I'm stuck so close to the end of my app.
I guess cross-origin might be the issue but I'm able to get URLs without issues if I don't have to set cookies, so I am a bit lost there.
Please let me know how I can get http://example.com/getmovie.html with a specific cookie header.
Thanks for your help
im sorry to inform you but the xmlHTTPRequest function of javascript does not allow a cookie header to be set for security reasons as shown here: Why cookies and set-cookie headers can't be set while making xmlhttprequest using setRequestHeader? the best way i could see you making that get request would be to a proxy server that you would be running. I believe that it is built this way to prevent you from setting cookies on domains that you do not own, furthermore i do not see an alternate resolution to this problem as no were in the docs i looked at was cookie persistence or management mentioned
In case someone has the same issue:
I didn't find a solution to sending a cookie with javascript. However, in my situation, the origin of the request didn't matter, only the cookie did. My solution was then to create a PHP file receiving the destination URL and the cookie content as parameters, and then sending the get request with the cookie as a request header. (more information about how to do so here: PHP GET Request, sending headers).
In my javascript I then use XMLHttpRequest to connect to my PHP file (hosted online) with simple get parameters and I then receive the response from the PHP. That trick of course won't work if the origin of the request matters (except if you host your file at home I guess, but in my case I want my application to work even if my WAMP isn't on).
Well... the problem here is the line xhr.setRequestHeader('Cookie', 'mycookie=cookie'); line just because the 'Cookie' header is reserved for the client browser to send the stored cookies. This means you are trying to do what the browser already does. When you send a any request, the client browser automatlycally will take all the cookies related to the site you are requesting and put them on the 'Cookie' header, you don't need to do anything else, if your cookie exist in your browser, it will be send.
Cordova how to send session cookie, allow credentials with XMLhttprequest:
// JS
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/ajax.php', true);
xhr.withCredentials = true;
xhr.onreadystatechange = function() {
if(xhr.readyState == 4 && xhr.status == 200) {
// alert(xhr.responseText);
// Get header from php server request if you want for something
var cookie = xhr.getResponseHeader("Cookie");
// alert("Cookie: " + cookie);
}
}
xhr.send();
// Php
// You can add cookie to header and get with (session works without it)
header('Cookie: PHPSESSID='.$_COOKIE['PHPSESSID']);
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: GET, POST, OPTIONS');
header('Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Request-With, Set-Cookie, Cookie, Bearer');
header('Access-Control-Allow-Credentials: true');
header('Access-Control-Max-Age: 86400');

Set-Cookie for a login system

I've run into a few problems with setting cookies, and based on the reading I've done, this should work, so I'm probably missing something important.
This situation:
Previously I received responses from my API and used JavaScript to save them as cookies, but then I found that using the set-cookie response header is more secure in a lot of situations.
I have 2 cookies: "nuser" (contains a username) and key (contains a session key). nuser shouldn't be httpOnly so that JavaScript can access it. Key should be httpOnly to prevent rogue scripts from stealing a user's session. Also, any request from the client to my API should contain the cookies.
The log-in request
Here's my current implementation: I make a request to my login api at localhost:8080/login/login (keep in mind that the web-client is hosted on localhost:80, but based on what I've read, port numbers shouldn't matter for cookies)
First the web-browser will make an OPTIONS request to confirm that all the headers are allowed. I've made sure that the server response includes access-control-allow-credentials to alert the browser that it's okay to store cookies.
Once it's received the OPTIONS request, the browser makes the actual POST request to the login API. It sends back the set-cookie header and everything looks good at this point.
The Problems
This set-up yields 2 problems. Firstly, though the nuser cookie is not httpOnly, I don't seem to be able to access it via JavaScript. I'm able to see nuser in my browser's cookie option menu, but document.cookie yeilds "".
Secondly, the browser seems to only place the Cookie request header in requests to the exact same API (the login API):
But, if I do a request to a different API that's still on my localhost server, the cookie header isn't present:
Oh, and this returns a 406 just because my server is currently configured to do that if the user isn't validated. I know that this should probably be 403, but the thing to focus on in this image is the fact that the "cookie" header isn't included among the request headers.
So, I've explained my implementation based on my current understanding of cookies, but I'm obviously missing something. Posting exactly what the request and response headers should look like for each task would be greatly appreciated. Thanks.
Okay, still not exactly what was causing the problem with this specific case, but I updated my localhost:80 server to accept api requests, then do a subsequent request to localhost:8080 to get the proper information. Because the set-cookie header is being set by localhost:80 (the client's origin), everything worked fine. From my reading before, I thought that ports didn't matter, but apparently they do.

Display cookies in request headers in Safari 7

When examining request headers in Chrome or Opera using their default console, I can see in the request headers what cookies have been sent to the server and if server is trying to set a cookie, I can also see Set-Cookie header.
However, in Safari 7.1.2 I don't see these information, but I see other information such as Accept,, User-Agent, Referer etc.
Do I need to enable something to see the cookies in the Safari's console? How can I view cookies that are being sent together with the request?
Thanks
P.S. I know that I can see cookies in the resources, but I need to know specifically in which requests the cookies are present.
As far as I know, modern versions of Safari will omit the "Set-Cookie" and "Cookie" headers in the responses, and requests, respectively. I guess the reason is "oh, you can see what cookies are set in the "Resources / Cookies" tab. However, that's of poor consolation when you're trying to determine if any Cookie headers are being sent, which is my situation.

Why isn't Ember.js seeing the Access-Control-Allow-Origin header from my server?

My app is an Ember.js front end with a Go API on the server. I created the Ember app using the FixtureAdapter. Now that I have the Go API back end I converted it to RESTAdapter.
When I hit my API directly with the browser, I seem to get the appropriate CORS headers back:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin,x-requested-with
Access-Control-Allow-Methods:PUT,PATCH,GET,POST
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:Content-Length
However, when my Ember.js app hits the API, I get XMLHttpRequest cannot load https://192.168.59.103:8001/notifications. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.59.103:9000' is therefore not allowed access..
I don't know how else to see what's going on between Ember and the API. I've read this CORS tutorial and everything seems to be okay on the server end.
I included the bit about x-requested-with because of another Stack Overflow question suggesting that jQuery requests need something different than plain old JavaScript requests.
Your endpoints also need to respond with CORS headers to OPTIONS requests- those will execute before the actual request to make sure that the request is allowed first.
Do you happen to be using Nginx as your reverse proxy for your API? If so, we experienced this same issue. In our case, the problem was that Nginx returns the correct CORS headers just fine for HTTP 200 OK responses, but for any error response, it will fail to add the COR headers and therefore the actual server response gets obscured by the browser complaining that it doesn't have the appropriate CORS headers to render a response.
See https://serverfault.com/a/431580/199943.
Even if you're not using Nginx, try calling your API directly (e.g. using Postman to avoid the CORS restrictions to see what it's returning. If your API is returning anything other than an HTTP 200 OK, that may be why the CORS headers aren't getting added.