In my previous understanding, for a web site, only login user of a web site (no matter what login/authentication approach is used) could have cookie as persistent identifier, so that if the user close the browser, open browser again to go to the same web site, the web site could remember the user.
But I learned recently that it seems for non-login user, there could still be a cookie associated with the user (after the user close browser, and then open the browser again to go to the same web site, the web site could remember the user), and it is called browser cookie? Is that true?
If it is true, who is responsible to set the browser cookie? i.e. need some coding/config at web server side, client browser configuration (without coding from server side), or both? How could web server access such cookie? Appreciate if any code samples.
thanks in advance,
George
Whether you actually "log in" or not is irrelevant to what cookies are stored.
If the browser requests a page, and the server includes a Set-Cookie response header, then the browser will store the value of that cookie in a local cache and every time it requests a page from the same server, it sends the value of the cookie back as well (in the Cookie request header).
It just so happens that when you "log in" to a website, the website will usually use the Set-Cookie header to tell the browser to store a value that indicates that you're already logged in (and your user-id and some other security-related stuff). But there's nothing stopping the web server from using Set-Cookie at any other time.
Related
I am having trouble understanding how a session is restored via cookies. How do the client know which sessionID cookie to send to the server via the HTTP request the first time? Does the client send all cookies and the server accepts the one that it also knows?
For example, let's say there are websites A and B (both using PHP), and I logged into both websites and then closed my browser. Now I open the browser again and go to site A and see that I am kept logged in. In this scenario, when my browser sends the HTTP request, the cookie whose file name contains the session ID for site A must have been included in the header. However I have two sessionID cookies for both site A and B. As far as I understand, the host name is usually not stored in the cookie, at least in many PHP tutorials of the setcookie() function. How do my browser know which sessionID cookie is for site A? Does the browser just send all cookies to A and let A figure out which is the right one by comparing all the received session IDs with stored session IDs? This does not sound right to me.
I was using Fiddler see on-the-field how web sites use cookies in their login systems. Although I have some HTTP knowledge, I'm just just learning about cookies and how they are used within sites.
Initially I assumed that when submitting the form I'd see no cookies sent, and that the response would contain some cookie info that would then be saved by the browser.
In fact, just the opposite seems to be the case. It is the request that's sending in info, and the server returns nothing.
When fiddling about the issue, I noticed that even with a browser cleaned of cookies, the client seems to always be sending a RequestVerificationToken to the server, even when just looking around withot being signed in.
Why is this so?
Thanks
Cookies are set by the server with the Set-Cookie HTTP response header, and they can also be set through JavaScript.
A cookie has a path. If the path of a cookie matches the path of the document that is being requested, then the browser will include all such cookies in the Cookie HTTP request header.
You must make sure to be careful when setting or modifying cookies in order to avoid XSS attacks against your users. As such, it might be useful to include a hidden and unique secret within your login forms, and use such secret prior to setting any cookies. Alternatively, you can simply check that HTTP Referer header matches your site. Otherwise, a malicious site can copy your form fields, and create a login form to your site on their site, and do form.submit(), effectively logging out your user, or performing a brute-force attack on your site through unsuspecting users that happen to be visiting the malicious web-site.
The RequestVerificationToken that you mention has nothing to do with HTTP Cookies, it sounds like an implementation detail that some sites written in some specific site-scripting language use to protect their cookie-setting-pages against XSS attacks.
When you hit a page on a website, usually the response(the page that you landed on) contains instructions from the server in the http response to set some cookies.
Websites may use these to track information about your behavior or save your preferences for future or short term.
Website may do so on your first visit to any page or on you visit to a particular page.
The browser would then send all cookies that have been set with subsequent request to that domain.
Think about it, HTTP is stateless. You landed on Home Page and clicked set by background to blue. Then you went to a gallery page. The next request goes to your server but the server does not have any idea about your background color preference.
Now if the request contained a cookie telling the server about your preference, the website would serve you your right preference.
Now this is one way. Another way is a session. Think of cookies as information stored on client side. But what if server needs to store some temporary info about you on server side. Info that is maybe too sensitive to be exposed in cookies, which are local and easily intercepted.
Now you would ask, but HTTP is stateless. Correct. But Server could keep info about you in a map, whose is the session id. this session id is set on the client side as a cookie or resent with every request in parameters. Now server is only getting the key but can lookup information about you, like whether you are logged in successfully, what is your role in the system etc.
Wow, that a lot of text, but I hope it helped. If not feel free to ask more.
Suppose I have logged into an application which is running from IIS. Now I haven't logged out, but closed the browser. And when I'm accessing the application again, it defaults to the login page. How does IIS recognize that it is a new request and redirects the user to the login page?
I have another question. Suppose if I'm not closing the browser, which I used when I logged in. I'm opening the new browser to request a page from same application. IIS recognizes that it's a new request to the application and redirects the user to login page. Why does it not use the existing session or cookies which the first browser uses?
Please don't get irritated of my continuous questions... I am having huge confusion.
We say HTTP is a stateless protocol. Once the page is requested I have logged in. And the HTTP protocol connection will be terminated between IIS and browser, right? Then I am navigating to other pages in that logged in application. Now IIS recognises the user has logged in on this browser. But when I open a new browser and request that application, how does IIS recognises it is a new request? Since the HTTP protocol is disconnected, how does it work in the first case?
As you've correctly said, HTTP itself is stateless, and each request is technically separate from every other. Sessions, as used by web sites, are a workaround for that. What happens, normally, is that the server stores whatever info it cares to maintain between requests (like the logged-in user's username and/or ID, for example), and assigns that information an ID (called a "session ID"). It then tells the browser that session ID, in such a way that the browser can hand the ID back when it's time to make another request. If the browser plays its part and provides the session ID, then the stored information can be retrieved, updated, etc with each request, providing some degree of state even over a stateless protocol.
Sessions are usually implemented using cookies. That is, the server hands the browser a cookie with the session ID, and the browser hands back that same cookie with each request until the cookie expires or is otherwise forgotten. Some cookies (so-called "session cookies") aren't saved, and are forgotten when the browser is closed. A freshly opened browser doesn't have any session cookies to pass, so if the server uses session cookies to do sessions (which it should), it will consider the user not yet logged in and bounce them to the login page if they need to be logged in.
Session cookies will usually be shared between tabs in the same browser, and will sometimes even be shared by windows opened by "File > New Window" from an already running browser, because both of those cases will typically just be a part of that browser. But if you start the browser from the Start menu, or however your OS lets you start a program, it's a whole other process -- and session cookies are rarely shared between processes.
The server typically also only remembers sessions on its end for a limited time (anywhere from seconds to years, depending on the server and/or site settings) after each request that uses the session. If the browser passes a cookie that corresponds to a session the server no longer remembers, it'll act as if there's no session at all. Which, in cases where you have to log in, will again bounce to the login page.
There are cookies that are passed always no matter are you logged or not. They are mapped to session in IIS.
Check out the following articles. They might be helpful.
IIS Dropping Sessions
Session Management in ASP.NET
We have a non-SSL ASP.NET web app that allows a user to login (ASP forms authentication, inproc).
Once authenticated, we redirect their browser to an external, SSL secured page on another web site / domain altogether that we do not control.
The client is redirected back to a pre-configured url on our original http web app when done.
However, the customer is then asked to "re-login" again on our side which is undesired...
It seems the forms authentication cookie is destroyed when transitioning between HTTP and HTTPS and back again.
How can I keep the forms authentication cookie alive so that the customer does not have to re-authenticate on the round trip?
It's not being destroyed; you're not authenticating on your domain, so the cookie's not being set on your domain, and thus requests on your domain will not contain said authentication cookie.
This is GOOD. If this didn't happen, then every cookie from every domain you ever visited would get sent with every request. Which is obviously 1) crazy and 2) a security hole. Setting a cookie on mydomain.com should never be visible to pages on myotherdomain.com.
If you're using a 3rd party authentication system, like google, facebook, etc, they'll all have some sort of callback token that you'll have to process and set your own cookies.
Consider to set cookie's domain property for your cookies with more specified can be found here or try this code:
Response.Cookies["your_cookie_name"].Domain = "yourdomain.com";
You're looking for a Single Sign On solution.
It might be a little overkill for your problem, for which you might just want to get the same domainname. But if that isn't an option you might want to take a look at:
Windows Identity Foundation
The question that I have is very basic: Is there a way to inform the web browser that the content of the cookie has changed?
I don't want to keep looking at the file and check if it has been updated because it'll cause performance degree on my app.
Thanks in advance!
It's always the job of the server to "push" the new cookie to the browser (in ASP.NET, by setting Response.Cookies("cookie_name")).
I'm not sure to understand your concern, only your application can know that the user's cookie needs to be changed, but it's usually not stored as a file on the server.
You would probably have to check for the Cookie or Set-Cookie http headers that come with the ASP page whenever it reloads in your application, though this would not account for changes made by javascript.
If the ASP page is refreshing each time a cookie changes, that is likely to be a much larger overhead than the WPF reading the cookie from the disk.
Well, since the ASP page needs to be active in order to SET the cookies, why couldn't you just use a HttpClient to request the cookies in your WPF app and on the server, set the cookies. Then send HTTP Response depending on whether or not you set the cookies. If you receive a 200 OK response, you can know your cookies are set. If there's an error, send a 500 Server Error back.