Open TridentTrue opened 3 years ago
I'm experiencing this same issue and it has forced me to switch to Insomnia for tests, even though Postman has more of the features that my team needs. It seems like a pretty basic requirement - when you have APIs hosted in subdomains (like api.your-domain.com) versus static web assets etc coming from your main domain or a generalized app domain (like app.your-domain.com).
I think there’s some confusion regarding non-host-only cookies.
TLDR: Adding the cookie's Domain
attribute will make it non-host-only and match with the specified domain, or any of its subdomains.
Cookie's Domain
attribute specifies which hosts can receive a cookie.
If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. → host-only
If Domain is specified, then subdomains are always included. → non-host-only
For example, if you set Domain=postman-echo.com
, cookies are available on subdomains like www.postman-echo.com
.
@SylonZero If you are manually setting cookies via the Cookie Manager, you have to specify the Domain
attribute for it to match for subdomains.
But if you are facing a different issue where Postman is not setting cookies properly, please share the steps that we can use to reproduce that issue locally.
@TridentTrue The cookie manager accepts a domain name and it accepting a domain name with a leading dot is definitely a bug, as you can see Add Cookie
doesn’t work.
But looks like Set-Cookie is not working because of the .local
domain. We are tracking this issue here: https://github.com/postmanlabs/postman-app-support/issues/10620
I think I am experiencing a similar issue.
I send a request to a server bar.foo.local
that responds with a Set-Cookie
that includes the following anonymized value:
cookieName=cookie-value; Path=/api; Domain=foo.local; Max-Age=36000; Expires=Fri, 13 May 2022 01:33:15 GMT; Secure; HttpOnly; SameSite=Strict
foo.local
and the cookie in the list as expected.foo.local
or bar.foo.local
or zar.foo.local
, Postman does not send that cookie with the request.As a workaround I;
Domain
attribute to include the subdomain I want the original cookie to be effective on, This makes the cookie available to other subdomain requests.
If;
the operation fails without an error or a warning, resulting in a default cookie named Cookie_n
I use the same requests in my application and Chrome Browser handles it as expected; sending the cookie set for a domain along with its subdomains. Am I missing something or is there something that needs to be fixed? This might be a very long shot as I have no idea about Postman internals but it feels like after storing a cookie, Postman cannot match the stored cookie with the new request URL.
Postman for Windows
Version 9.18.2
UI Version 9.18.2-ui-220511-0750
Desktop Platform Version 9.16.0
Architecture x64
OS Platform win32 10.0.19043
I can confirm that as soon as I set Domain=app.local
in my cookies, I don't see a hidden header for Cookie at all, even in that same request. Omitting the domain works fine, but doesn't allow the cookie to be shared across subdomains. Setting my local domain to app.example.com
(using a reserved .com domain) has worked around the issue.
Having similar issues.
When I receive 2 Set-Cookie
headers in the response (see pic 1), my cookies aren't set (see pic 2).
TEMP FIX: When I change application.local
to api.application.local
(explicit sender) everything works fine in Postman. However, the browsers like Chrome don't like this, since they need the base URL (application.local
) to set it.
These are my cookie settings:
I think I'm having a similar issue, but it doesn't look this issue was resolved.
I am using a local domain that is proxied through apache on my dev PC (MacOS).
When I send a request to to the API I can see the set-cookie header in the response on the console, but postman' cookies tab says there aren't any cookies received, however opening the cookie dialogue they are listed under my dev domain of home.local.
Below are the response headers
Below is what I see in the cookie tab of the response
Below are the cookies in the cookie dialogue
Due to this issue, any other requests to other endpoints due to a CSRF token mismatch (I am sending the X-XSRF-TOKEN header but I think it needs the other cookies as well to work. The same request works in Insomnia Rest client, but I have recently started using Postman.
I found that if I hadd a pre-request script with the following:
const url = pm.environment.get('base_url');
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'))
}
});
It still didn't work on my dev environment, but it does on my production environment.
However, changing my local dev URL from my-app.home.local to my-app.home.com now works and the cookies are received and sent in the next request as expected.
Is there any update to this issue? I have the same problem. 😓
Is there any update to this issue? I have the same problem. 😓
No it seems not, the issue hasn't been updated since its creation in 2022. We ended up dropping Postman and moved to Insomnia instead.
Is there an existing issue for this?
Describe the Issue
When trying to set a cookie via the Set-Cookie response header, Postman will trim leading '.' characters from the domain field meaning the cookie does not work for subsequent requests. e.g. ".mywebsite.com" will become "mywebsite.com"
Additionally, when trying to set a cookie manually in the "Manage Cookies" window for a domain that has a leading '.' the "+ Add Cookie" button is unresponsive. If you then click the 'x' button to remove this domain it gets replaced instead with the same domain but with the leading '.' removed, similar to the above.
Steps To Reproduce
Manual Method:
Set-Cookie Method:
Screenshots or Videos
Manual Method:
Set-Cookie Method:
Environment Information
Additional Context?
This is not an obscure custom implementation. All of our auth is handled by IdentityServer4 which is used by many .Net based applications.