I don't understand why the following response is not able to set cookies.
It works in localhost.
Related
I've recently started using Postman and I am testing an API where I get a CSRF token and then login but I always get a CSRF token mismatch. I am including X-XSRF-TOKEN header but I think the issue is around the cookies not being stored correctly.
I am calling a Laravel Sanctum endpoint to get a CSRF token and when I look in the in the console I can see Set-Cookie response headers
However, when I look in the cookies tab it says no cookies were received from the server
However, when I look at the cookies store they are listed for my test domain (home.local)
Due to this issue, when I send a request to the login, the session cookies are not sent in the request as shown in the console on the request to the login endpoint
I can do this fine using Insomnia.Rest client so I know the API is working as expected - I am however trying to replace Insomnia with Postman.
I've tried Google, but I've only found some bugs that were introduced that seemed to cause something similar back in 2016
Update
I managed to Postman working with production fine using a pre-request script to get the CSRF token and set the environment variable using the below:
const url = pm.environment.get('base_url');
const referer = pm.environment.get('Referer');
pm.sendRequest({
url: `${url}/sanctum/csrf-cookie`,
method: 'GET',
}, function (err, response, {cookies}) {
if (!err) {
console.log("cookies", cookies);
pm.environment.set('xsrf_token', cookies.get('XSRF-TOKEN'))
}
});
Although this worked on production and successfully did the POST request, on my local dev PC, I was still getting the CSRF mismatch.
Although the request/response looked the same between dev/and prod I for some reason had the idea to change my dev URL from my-app.home.local to my-app.home.com and now the cookies are received and send in the next request to login without getting a CSRF token mismatch.
There's clearly an issue with postman here but not sure if it's something I'm doing or a bug in Postman. Does .local mean something different?
I am trying to set a cookie using go in the chrome browser but can only get it to set in postman.
The cookie successfully sets in postman but is simply not setting in chrome with no error.
I have set CORS as default using this package https://github.com/gin-contrib/cors as I have had issues with CORS requests in the past and this seemed to solve the issue.
I set the cookie using:
c.SetCookie(
"TOKEN",
tokenString,
3600,
"/",
"localhost",
false,
true)
I have tried replacing localhost with http://127.0.0.1 which again works in postman but not chrome or firefox. I have also tried setting the cookie with the http package instead but this has failed in the same way.
EDIT I have also tried domain as blank ("") but this has the same outcome.
You passed true to the secure argument of SetCookie but you're sending the cookie to an insecure http address.
As per the MDN docs:
A secure cookie is only sent to the server with an encrypted request over the HTTPS protocol.
I just heard about CORS, and wanted to know if it can help me in what I wanted to do.
There is a website that has CORS enabled on its server. If a user has a client session running on his browser, I wanted to access this from my server. I want this cookie to authenticate that person on my server.
Is that possible?
Can someone give me a very detailed guide, tutorial or a working example of this?
Yes, this is possible, if the server responds with the Access-Control-Allow-Credentials: true response header. This header must be set by the server in order to exchange cookies. On the client side, they must set the XMLHttpRequest withCredentials property to true. See here for more details: http://www.html5rocks.com/en/tutorials/cors/
I have a website that uses asynchronous http requests (ajax, to use the common misnomer) for performing login and registration. The authentication cookie is set by the asynchronous request and it all works great.
I recently locked down the registration and login actions to require https. Everything appears to work, except that the authentication cookie returned isn't functioning properly and the user doesn't actually get logged in.
In Chrome, in the development tools, under resources, it doesn't show any cookies having been created. If I go to the Chrome settings and view all the cookies, I can see that a cookie has been created. Perhaps it's encrypted and not readable?
So, to summarize:
The initial page is loaded using normal HTTP
The Login action is an asynchronous HTTPS request
The authentication cookie returned by the HTTPS request doesn't seem to be working
How do I get this to work?
A couple things I should note:
This is not a CORS issue.
I am aware of the potential man-in-the-middle attack. This website does not house sensitive data. I'm attempting to do something very similar (if not exactly the same) to what reddit is doing.
I managed to figure this out. Turns out that in the Http response, you need to set the Access-Control-Allow-Credentials header to true. Also, you must set the withCredentials to true on the client-side http request.
I've managed to make a CORS request on IE8 using XDomainRequest. However it seems the cookies are not sent on IE8. Is there any hack for that ? The request is made from buy.example.com to buy.api.example.com
There is no way except to include the authentication cookie value / token in the query string e.g. : buy.api.example.com/?sessionId=$sessionId&otherparameters=test and set your webservice to check the query string if cookies are not present.
There is another way. If you use SSL on the non-default https port, it will keep sending the cookies.
For example, if your URL is something like this https://example.com:8443/xxxx, then it will send the cookies.
I experience the same issue you have. My web app (internal web app) was working with https but in a non standard port and it just works fine. When I configure to use 443, it stops working because the cookies are not sent by XDomainRequest object.
I hope this will help