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.
Related
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.
I'm a little confused about the cookie and I want to know can we use cookies somewhere other than the browser, like a mobile app or desktop app. Is the cookie dependent on the browser?
No, cookie is not dependent on browser.
Cookie is dependent on HTTP "User-Agent" -- the software/library client that is acting on behalf of a user, following HTTP protocol. Browser is just one type of it. Other types of "User-Agent" includes:
CLI software that can send HTTP request, such as curl or wget.
Library that can be imported in project and send HTTP request. Take Node.js project for example, they can be request or axios. All major programming language have its own HTTP client libraries.
Self-implemented HTTP client logic code.
more...
In a mobile app or desktop app, if HTTP is used for application, it is highly likely that cookie is used.
Any HTTP client can use cookies. A cookie is just a HTTP header sent by the server, with a value that is sent back to the server by the client in subsequent requests. Consult the documentation of your HTTP client to see if there is built-in support for remembering cookies.
Session Based Authentication
In the session based authentication, the server will create a session for the user after the user logs in. The session id is then stored on a cookie on the user’s browser. While the user stays logged in, the cookie would be sent along with every subsequent request. The server can then compare the session id stored on the cookie against the session information stored in the memory to verify user’s identity and sends response with the corresponding state!
Token Based Authentication
Many web applications use JSON Web Token (JWT) instead of sessions for authentication. In the token based application, the server creates JWT with a secret and sends the JWT to the client. The client stores the JWT (usually in local storage) and includes JWT in the header with every request. The server would then validate the JWT with every request from the client and sends response.
The biggest difference here is that the user’s state is not stored on the server, as the state is stored inside the token on the client side instead. Most of the modern web applications use JWT for authentication for reasons including scalability and mobile device authentication.
Scalability
Session based authentication: Because the sessions are stored in the server’s memory, scaling becomes an issue when there is a huge number of users using the system at once.
Token based authentication: There is no issue with scaling because token is stored on the client side.
Multiple Device
Session based authentication: Cookies normally work on a single domain or subdomains and they are normally disabled by browser if they work cross-domain (3rd party cookies). It poses issues when APIs are served from a different domain to mobile and web devices.
Token based authentication: There is no issue with cookies as the JWT is included in the request header.
Token Based Authentication: using JWT is the more recommended method in modern web apps. One drawback with JWT is that the size of JWT is much bigger comparing with the session id stored in cookie because JWT contains more user information. Care must be taken to ensure only the necessary information is included in JWT and sensitive information should be omitted to prevent XSS security attacks.
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.
I'm experimenting with moving an existing enterprise app to HTTP 2.0 at my customer's request. The app uses ASP.NET Forms Authentication, and when accessed over HTTPS with HTTP 2.0-aware browser and server (Windows Server Tech Preview), authentication appears to succeed during the login action, redirecting to the requested URL, but then the server responds to the next request with a redirect back to the login URL again. After adding some diagnostic logging to Application_BeginRequest, I found that the auth cookie is present in the request, but an attempt to decrypt the ticket with FormsAuthentication.Decrypt() throws an exception stating that there are non-base-64 characters in the cookie. I suspect this has something to do with HTTP 2.0 header compression, but I would have thought that this should have been handled transparently by IIS and that the headers should have been decompressed by the time my code executes. Has anyone else experienced this and know of a workaround? Happy to provide additional information if I left anything out.
I am .net Beginner,when the log-in request send from client to server in forms authentication
the server will sends authenticated cookies back to client after successfull log-in ,at every request cookies will sends to server.
so can we see this cookies on browser if yes then how?
Cookies can be read using this: http://www.w3schools.com/js/js_cookies.asp
I don't think the .NET framework cookies are exposed to the client, but could be wrong. Some cookies, if a setting is enabled on it (called HttpOnly) are server-only cookies and can't be read on the client. The name of the cookie is configurable in the web.config's element.
HTH.