I am calling API at https://engine-beta.mydomain.com/list* inside http://localhost.mydomain.com website, API response with set-cookie: with domain landing.vahanacloud.com. The browser is ignoring(not saving) this cookie.
But with the same scenario, in API response with set-cookie: with domain .maydomain.com is working fine.
It is because you host domain and you domain is different.
Host Domain: Where the api is deployed.
App Domain: Where you web app is running.
If you save cookie to parent domain, all the sub domain will have access to cookies but siblings domain will not have access to other sibling cookies.
Related
I just set up my custom domain with Firebase Hosting, lets call it mydomain.example.com.
When I navigate to it in Firefox, it shows a toggle next to the domain, that when clicked shows this:
Where the redacted part is my firebase project ID, and the full domain is one of the default domains for Firebase hosting.
What is happening here, exactly, and how can I change the behavior so it doesn't result in these cross-site cookies? Is this related to the Google Auth provider, which I also noticed doesn't use the new custom domain (instead, using one of the default domains) in the popup window for sign-in?
This is a known issue with the Firebase Auth SDK. It is not related to the Google Auth provider. The issue is that the Firebase Auth SDK uses a cookie to store the user's session. The cookie is set to the domain of the Firebase project, which is a default domain for Firebase Hosting. The cookie is set to be secure, so it is not sent over HTTP, but is sent over HTTPS. The cookie is also set to be SameSite=Lax, which means that it is not sent on cross-site requests unless the request is a GET request. The cookie is not sent on cross-site requests that are POST requests, which is the case for the sign-in popup. The cookie is sent on cross-site requests that are GET requests, which is the case for the main page.
To solve this issue, you can set the cookie policy to SameSite=None. This will allow the cookie to be sent on cross-site requests, but it will also require the cookie to be marked as secure. This means that the cookie will only be sent over HTTPS. If you are using a custom domain, you will need to set up HTTPS for your custom domain. If you are using a default domain, you will need to set up HTTPS for your default domain.
I'm building a web application that uses cookies to track the user session. These cookies work flawlessly in development on localhost but they aren't working correctly in production. I suspect this is because I have some cookie settings misconfigured but I'm not sure which.
One thing to note is that the webapp runs at app.goldsky.com and the api runs at api.goldsky.io (note the different TLDs).
The application I'm building uses a tool called WorkOS for user authentication.
The authentication flow is as follows:
User visits website, enters their email and presses the login button
Request is sent to backend (api.goldsky.io)
Backend generates an authentication URL using the WorkOS SDK (of the form api.workos/...) and sends this to the frontend
the frontend navigates to this WorkOS authentication URL and proceeds through the auth flow
If successful, WorkOS redirects the user to my backend (api.goldsky.io/auth/workos/callback)
My backend generates a session token, sets a secure, httpOnly, path=/ cookie with the session token (goldsky_session=...) and redirects the user back to the webapp (app.goldsky.com)
In localhost this all works flawlessly. However, in production I don't see the cookie persist after step 6 completes.
In production, the response to step 5 contains the cookie
however after the redirect back to the webapp, the cookie seems to disappear. Here's the request to app.goldsky.com (the redirect from step 6) and it doesn't have the cookie header.
and just for completeness, here's a screenshot of the cookies for app.goldsky.com - it's empty:
By comparison, the final redirect on localhost contains the cookie:
How come my cookie does not persist after redirecting from api.goldsky.io to app.goldsky.com? Do I need to set the Domain attribute for the cookie? If so, what should I set it to? Maybe this is a SameSite problem?
Turns out I had an nginx misconfiguration issue which was rejecting requests to specific paths. Nginx was only allowing requests to /auth and a few others. My login logic was under /auth but the user query was at /user which nginx was rejecting.
When I go to the HTTPS server, I can see in Developer tools (or in Fiddler) a request cookies that are send to the server by client. But how client know, which cookies should be sent, if no response cookies are sent by server. At least I can´t see any response cookies in Developer tools or Fiddler.
First up each domain has its own cookies in a cookie jar / cookie store. Whenever a request is made by the browser to the server all cookies in the store for that domain or subdomain will be sent to the server.
secure cookies vs insecure cookies
Secure cookies will be sent only on connections that are made over ssl(https protocol). Normal cookies will be sent on both http and https protocols.
session cookies vs. persistent cookies
session cookies - These cookies persist as long as the browser session is open. This means that Once you have cleared cache or closed the browser they get lost.
persistent cookies - These will persist even if the browser is closed and opened again unless you have set the browser to clear cookies on exit in which case they will behave just like session cookies.
First party cookies vs. Third party cookies.
First party cookies - generated by the domain currently open as main document - this means they have same domain as the one displayed in your browser.
Third party cookies - generated by a different domain then currently opened by the browser(in the addressbar) but which are managed inside an iframe or various resource calls like css, script, media(images, videos or other embedded media)
CORS - cross domain calls via xhttp ajax calls - this case arises when you create a domain requests resources from another domain via xhttp(ajax calls). In this case the browser makes a preflight check to see if the receiving domain accepts queries from the origin domain(origin headers are sent to the domain to check the cross domain policy). The server must necessarily respond with a valid options header and the server may allow identity data which is short for cookie data. If the remote domain has answered correctly with an "Access-Control-Allow-Origin" header that allows your domain or "*" then you are allowed to send cookies via this request. And these will behave just like normal calls.
To read more about cors:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
To directly answer the question: the client sends back all cookie data it has for that domain and path.
If you do not see any Set-Cookie header in any HTTP response, it may be because the cookie has been issued by server and stored on your computer before you started looking at Dev Tools or Fiddler. It could have been up to a few days, weeks, even months ago.
In Firefox, if you navigate to about:preferences#privacy and click Manage Data, you can see which domains already have cookies issued and stored on your computer. The Storage tab in Firefox Dev Tools can show you details of all cookies. The expiry of the cookie is determined by the server, using the Expires or Max-Age directive in the Set-Cookie header.
How a cookie first ended up on the client computer:
Client makes its first ever HTTP request to server, e.g. GET www.example.com
Server creates a cookie and sends it back in the HTTP response, e.g. the response headers contains a line: Set-Cookie: sessionID=1234567; path=/; Max-Age=31536000
The client receives HTTP response and stores the cookie in the "jar" for domain www.example.com.
How server uses cookies to identify the client
In subsequent HTTP requests to domain www.example.com, the client sends back all cookies in the jar that matches the path or sub-path. For example, the client wishes to issue a request GET www.example.com/about, sees that the URL is a sub-path of / in domain www.example.com, so it sends the cookie as a line in the HTTP request header, i.e. Cookie: sessionID=1234567.
The server sees the cookie and knows exactly which client made this request.
We have a wild card domain hosted on azure. I've setup up subdomain.domain.com to rewrite to domain.com/subdomain. It all works fine.
However when I login to our identity server, once the login process is completed and I am redirected back to subdomain.domain.com it seems like the authentication token is lost.
I can't see how this can be possible. This issue happens with all our identity providers (google, Facebook, Microsoft live)
If I change the setup to use domain.com/subdomain then everything works as expected
The main issue is what type of cookie your identity server places,
It looks like your server places and domain specific cookie, and not a wildcard one.
Cookie domains
Common issue with the cookie for the authentication is the domain for the cookie. Similarly to the paths of the cookies, if the cookies are created on two different subdomains, then the cookie will only be accessible on the domain where it was created. For instance, your main application may be on www.domain.com, but you have Telligent Evolution running on cs.domain.com. If you create the cookie on www.domain.com, the browser will only send it to that domain, and it won’t be passed along when they navigate over to cs.domain.com.
The cookie can be carried over by setting the domain to “.domain.com”. Cookies don’t use the common “*” wild card. Simply use “.domain.com”. With this entry, the browser will not to pass the cookie when it goes over to cs.domain.com as well.
Like the path, the domain can be specified in either the web.config or through code. When setting the web.config file, it will only check for the authorization cookie. You must have this set for the site to correctly recognize the new domain level cookie:
<authentication mode="Forms">
<forms name=".CommunityServer" ... domain=".domain.com" />
</authentication>
The "domain" name is ignored by the FormsAuthentication.SetAuthCookie method, so you must manually set it on your login page when creating the AuthCookie. For example:
HttpCookie cookie = FormsAuthentication.GetAuthCookie(username, true);
cookie.Domain = ".domain.com";
Response.Cookies.Add(cookie);
I have two virtual directories, one hosts an application the other hosts a web service layer running WCF with ASP.NET compatibility mode enabled.
The service project has an HTTP module that deals with authentication for incoming requests. The login service writes an authentication cookie to the client.
Subsequent requests are handled via AJAX (jQuery) to the services from the application project (another virtual directory on the same domain.)
Cookie domain is set correctly, the cookie path is "/", the cookie is set to HTTP ONLY so that scripts cannot interact with it.
My issue is the login service seems to be sending the SET-COOKIE header with the correct payload in the cookie, however the subsequent requests are not sending the cookie back to the server, in fact when inspecting the local store the cookie is not even there.
Potentially what could be my issues?
We tracked the issue down to Chrome. Apparently there was a prior bug that seems to be presenting itself again whereby expires cookies are not promoted to session and are instead discarded.