I am trying to modify a cookie, specifically the pass_hash cookie that the ipb forums set. I have tried several different extensions for firefox to modify this cookie and set it, adn cannot seem to do so.
The cookie seems to expire as soon as it is created. I am trying to set it to expire one year from now. I can not modify this cookie in any form. Even deleting that cookie, and making a new cookie will not work...possibly since it is being over written.
Why is this the case, and is there any way to force it to stay?
I guess, it depends on the server-side. If you on the client side manipulate the cookie to live 'forever', the server still can delete it. If this ipb forum software has a policy of 'one-way' cookies, that is, deletes every cookie and writes a new one, or resets the expire date on the server side, there is nothing you can do about it.
Cheers,
Related
I visit the Information Commissioners Office (ICO) https://ico.org.uk/ which is the commissioner who is in charge of things like GDPR and cookies in the UK.
They have the option to opt out of cookies, which I duely did. I then refreshed and I could still see cookies being load for Google Analytics.
A few days later I returned and the cookie must have expired. Were my original findings due to browser cache? And if so, is there a way to force browsers to forget cookies? I would find this more compliant with the users wishes.
I think if a cookie can expire, then perhaps you could set the expiry date to now when a user opts out. Or set the cookie to 1900 or something similar so it expires. Or set it to null if that would make a difference.
Is it possible to remove a cookie instantly when a user opts out, or is that entirely down to the browser settings?
Yes. To force a cookie to expire, return one with your response with a matching path and name, but an expiry time in the past. The browser will consider it expired and delete it.
Pretty much every site using Google Analytics is going to be betraying your wishes (and breaking the law, at least in the EU), since that's what it's default configuration does, and it's very rare than anyone changes it to anything else.
I know there are session cookies and persistent cookies. As far as I can understand, session cookies are managed by browsers (e.g. ended when closing the browser). So my questions are: How do browsers end session cokies? Do they send some sort of request to a server that you technically also could do manually?
Some browsers like Chrome has the option to "start from where you left off by NOT ending the sessions. How does this technically work? How are the sessions kept alive? Even after restarting the OS, the sessions are still alive, just as if they were converted to persistent cookies.
From a technical perspective, the definition of a Cookie can be found here. Loosely, think of a cookie as a piece of data returned by the Web Server you connected to in the past. This data is associated with the host that returned that data and can never be seen by other hosts. When you subsequently connect to the host in the future, the previously returned value (the cookie value) is sent back to the server. This allows the server to generate some data that can be used to "remember you" when you subsequently come back.
A session cookie is still "just a cookie" but is used to maintain "state of the session". For example, imagine a shopping cart. If you place items in your cart, the server will send back a cookie value that is a key used to find your cart again. If you place items in your cart today and come back tomorrow, the server can use the cookie value to lookup your cart.
As for "ending a session" ... this can be done at the browser by asking the browser to "forget" the cookie such that when you subsequently visit the web site, there is no cookie and hence it has no knowledge of your past interactions. Alternatively, the server can choose to ignore any cookie value you sent. A cookie can also have an implicit self deletion value such that if a time has passed, the cookie evaporates. Finally, the server can ask for the cookie value to be replaced / deleted when you next visit it.
I would suggest having a good google at Cookies in general as there are a lot of good references to how they work and how they are used.
I was reading up on cookie validation and came across the question of how exactly does Django validates its cookie?
If I remember correctly, Django stores session id in the cookie for later use. Does that mean that anyone who fakes the cookie will be able to use arbitrary session data?
The validation itself is damn simple: against the data in in the session backend. As you can see here, the data you receive in a cookie comes from your session, session_key attribute. Where it is being stored depends on your session backend, by default it's the database.
It is impossible to "fake" a cookie. Unless someone stole your SECRET_KEY. More detailed info here.
If someone steals a cookie from a client, the thief can use the client's session till it expires. You cannot prevent it. If you are aware of such a case, the client's password needs to be changed ASAP, as it will lead to invalidation of ther user's existing sessions (starting from Django 1.10).
Upd: your question made me curious whether the session backend actually stores the value as is... Figures, it does. (I got also impressed there's pgAdmin for Windows)
When a user login in my website, it returns a cookie with two hours expire. The cookie is not returned in following calls, so after two hours the cookie expires even when the user is still using the website, and then redirected to the login page.
So I think I know the solution, but is it a good practice return the cookie with the "expire" updated in every call?
Cheers.
It's not a huge deal to set a session cookie in every server response, especially since the client is already sending it to the server in every request.
However, you can do better than that. If the client comes in with a cookie that's bound to expire, say, less than 1 hour and 50 minutes from now, you can send them a new cookie that's set to a new, 2-hour expiration date. You can easily keep track when a client cookie is set (and is therefore bound to expire) in your session handling code.
It boils down to why not? It solves the timeout problem, and has no drawbacks.
The only side effect is the additional bandwidth necessary to transfer the cookie, but this is completely negligible. If you do care about that bandwidth, only resend the cookie every n minutes.
I'm guessing Yes, but I'm not sure.
Both Authenticated Sessions and Anonymous Sessions would reference the stored sessions via the cookie.
########### edit: Clarify
It seems that sessions require some way of referencing for the stored session data.
This reference could be stored in a cookie OR added as a parameter in the URL.
I know this is taking you too literally, but it seemed appropriate to point out that HTTP is stateless and therefore does not have sessions. In order to maintain state, either the browser or the server have to persist the state information between requests. Traditionally, the server maintains the state, and by convention this is called a session, but it has nothing to do with HTTP as it is a workaround. Also, a session usually has a very specific connotation to it - namely that it is an individual visit to the site that will expire when it is no longer being used (some period of inactivity). It will also be different for the same user using different computers or browsers.
In order to achieve a server session, the server will generally set aside some information in memory or database to keep track of state and use a piece of identifying information to associate http requests with that state. This is usually a token. The browser needs to include information identifying the session with each http request. It doesn't matter how this happens, as long as the server and browser agree. It is most often a cookie, or url parameter as fallback, but as long as you set up the code right it could also be part of the url itself, part of a POST body, or even a non-standard http header.
The alternative that is becoming more and more popular is to maintain state in the browser and use purely ajax calls to the server. In this scenario, the server does not have to maintain any concept of session, and will simply return the data that is requested in a completely user-agnostic way. Some authentication may still be needed if the data is private, but a session token is not, and no state is kept on the server.
You can pass the session ID around as a query parameter (www.blah.com/index.php?SESSIONID=fADSF124323). But it has to be on every page. PHP has a option to enable this transparently. It is a huge mess. This is why cookies are preferred.
Not necessarily, some sites use a session ID value present in the URL that represents the session and this value gets appended to all links visited by the user.
We have to use it this way at work, since often mobile browsers don't accept cookies and this is the only way to remember a session.
Also there is HTTP-Authentication, not used often anymore today as the browser has to send username and password to the server unencrypted on every request.
HTTP-Auth just puts username and password in the header sent by your browser.
you can pretty much uniquely identify people by their browser plugins, fonts, etc.
https://panopticlick.eff.org/
When you're using SSL/TLS, then you could at least theoretically use the SSL session id to reference some state on the server.