I've looked around and found how to delete cookies on the client browser either using an expiration for the cookies or deleting them on browser exit by not providing an expiration.
I need to set the cookies in my web app to delete after a specific amount of time, but also if the browser exits or crashes. Is this possible?
Thanks in advance!
Is this possible?
No, this is not possible out of the box. There are 2 types of cookies:
persistent: one with expires property set for a given date => those cookies are stored as files on the client browser and survive browser restart. The will be sent along each request the client performs until the date at which they are meant to expire is reached or until the server explicitly removes them.
session cookies: one without expires property being set. Those live only in the memory of the current browser process but will never expire (until the browser is closed or until the server explicitly removes them).
So for your scenario you could use session cookies by including the created at date in the value. Then on the server upon each request you could read this value and compare with the current date. If the desired period has elapsed simply expire the cookie so that it is no longer sent on subsequent requests. By the way this technique is used the Forms Authentication module in ASP.NET. You specify a timeout in your web.config and decide whether you want to use a sliding expiration or not and then on each request the server checks whether the timeout is reached in order to take the decision of invalidating the cookie or renewing it (if sliding expiration is enabled).
Related
Everyone claims a domain must have two dots in order for a cookie to be stored, but that cannot be true, because Chrome is storing the cooking named "__RequestVerificationToken" received through the Set-Cookie header from ASP.NET; however, it refuses to store other cookies. I literally am sending a virtually identical cookie with a virtually identical Set-Cookie header, and yet Chrome is refusing to store it. The path is "/", just like the other one. No domain is set. The only difference is the name. Is Chrome giving "__RequestVerificationToken" some kind of special treatment?
Looks like Chrome will save "session" cookies for "localhost", but not "permanent" cookies. No idea why it makes the exception for "session" cookies, but the "permanent" ones aren't stored because cookies are only supposed to be stored for 2nd level domains (domains with at least 2 dots, which localhost is not).
"permanent" cookies are cookies that DO set an expiration date, which is a bit counter-intuitive, but they're "permanent" in the sense that they survive across browser restarts unlike "session" cookies which are supposed to be deleted when the browser closes. In reality, they're all relatively permanent, because Chrome/Firefox typically don't delete the session cookies when the browser closes, thanks to features like "continue where I left off" and "restore my tabs when the browser restarts".
Another takeaway is that we may as well not set an expiration on any kind of session or auth cookie at all, because it offers the following advantages: 1. it works on localhost, 2. it more secure in that they stand a chance of being deleted when the browser closes, and 3. they persist across browser sessions anyway if the user has the browser configured to do so, so setting a long timeout isn't necessary. Setting an expiration on the cookie also doesn't do you any good anyway, because it's just another value to sync with the server-side session, the value isn't sent to the server with the cookie anyway, so it's useless, and utimately the server-side expiration for the token (stored in session or database) is authoritative anyway. So just don't set an expiration on your session or auth-related cookies.
Concerning an HTTP session: It is either implemented via cookies or URL rewriting.
Since the HTTP 1.1 uses persistent connections, I assume that a session is invalidated when a TCP connection disconnects. Or not?
I am confused on this since otherwise the behavior using cookies vs URL-rewriting would not be the same,right?I mean the browser does not store the values part of the URL-rewriting to disk, correct?
Additionally if it is not, how could we programmatically invalidate it on the server when a tcp connection resets?Is there such e.g. listener in Tomcat?
Since the HTTP 1.1 uses persistent connections, I assume that a session is invalidated when a TCP connection disconnects. Or not?
This is wrong.
In Java the session is implemented via cookie, usually (tomcat, jetty,etc). A cookie called JSESSIONID=1234567 (the number is randomly generated and identifies the session) is set from the server on the first response, then it gets stored in the browser and is sent back to the server for every subsequent connection.
This cookie usually has default lifetime of 30 minutes, and survives when the tcp connection is interrupted. This allows the server to recognize the user across different connections.
URL rewriting means that every URL contains the JSESSIONID as part of the URL, on the server side nothing changes, except that the JSESSIONID value is read from the URL instead than from the cookie.
If the cookie was lost after the tcp connection was closed, it was completely useless. Imagine a chat system based on a persistent tcp connection: do you need a cookie if you can simply identify the connection from an identifier binded to the socket? No... The cookie is useful exactly because you need to track the user across several connections.
Since the HTTP 1.1 uses persistent connections,
They are persistent, in the meaning that after a first request (the html page), the same connection can be reused to send also other resources (images, css, javascript, etc). And the browser keeps the connection open for sometime after, to avoid recreating a new connection in case the user clicks to another link. It's just an optimization, it doesn't mean that when you open a URL in your browser, the connection keeps alive for all the time you lay on the same website.
Additionally if it is not, how could we programmatically invalidate it on the server when a tcp connection resets?Is there such e.g. listener in Tomcat?
On the server, you can always invalidate the session calling session.invalidate().
If you want to invalidate the session every time a request is made, then you simply don't need a session.
Cookie can also be invalidated on the client side via javascript.
I am confused on this since otherwise the behavior using cookies vs URL-rewriting would not be the same,right?I mean the browser does not store the values part of the URL-rewriting to disk, correct?
URL rewriting works where cookies are disabled. Basically, every time you click on a link, the JSESSIONID= is appended to the url, so the server will identify the user, and all the subsequent links will continue to be generated on the server having the same JSESSIONID. In this way, every POST or GET request will contain the identification of the user (the session).
The cookie works in the same way, only that instead of being hardcoded on the URL, it gets embedded in the HTTP request as header information, and this is done by automatically by the browser (unless it has been disabled).
It doesn't mean that it gets saved in the disk (for what purpose?), it just keeps it in memory, for session cookies (that expire when you close the browser or after 30 minutes).
You can set a longer life time for a cookie; in that case, the browser stores the cookie for a longer time. But usually those are not "session cookie", but are cookie used to identify a specific user (like a UUID). From the UUID cookie then you can create a new session cookie when the same user reconnects.
The session, is used to keep track of a CONVERSATION. The user closes the browser, the conversation ends. If there is a persistent cookie like a UUID, then you can use that cookie to create a new conversation and bind the new session to the same user you met before.
I'm implementing analytics event and page view tracking on a Roku box (brightscript). That part isn't so important, but know that JS is not an option, nor is cookie setting. I can set variables, but they're not typical cookies. Ok - so I've implemented a great solution (google-analytics-for-roku-developers/) and all is well - EXCEPT!!
Analytics doesn't seem to track uniques, and is listing ZERO. It is tracking events beautifully, however :)
Here's a sample of my URI request (decoded for clarity):
http://www.google-analytics.com/__utm.gif?utmwv=1&utmn=1736644096&utmsr=720p HDTV&utmsc=24-bit&utmul=en-us&utmje=0&utmfl=-&utmdt=RokuPageView&utmhn=Home&utmr=-&utmp=Home&utmac=UA-5035974-13&utmcc=__utma=1394882688.2097034752.1347384621.1347384621.1347384621.2;+__utmb=1394882688;+__utmc=1394882688;+__utmz=1394882688.1347384621.2.2.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none);+__utmv=1394882688.13C1CJ109560;
so, question #1 - I understand from the docs that the __utma is the element that tracks uniques. Do you see anything there that's wrong?
question #2 - The development code I implemented sends a NEW random cookie for EACH EVENT. That seems wrong to me. I'm considering changing it to a session-based cookie that persists through all events. That's when I'm way beyond my understanding. Any guidance on this?
I think the answer to #2 is the answer to #1. Basically, you need to emulate how a browser handles cookies within your code. A "session cookie" is just a cookie, that is, a value passed as an HTTP header along with the request and response -- what makes it a session cookie is that it's expiration date is set to the past, which tells the browser to delete it when the browser instance closes.
Cookies are pretty straightforward -- a mechanism to get around the fact that HTTP is stateless (has no memory). If you pass an HTTP header Set-cookie: <value> in the response, the client is supposed to remember the value and pass it back in a Cookie: <value> header in subsequent requests. (There's a bit more to cookies relating to domains and expiration, and so on, but it's not that much).
So if your client (the Roku) has some mechanism for persistance, then you just need to store any new cookie, then before setting a new random one, check the header and if the cookie has been stored, just send it back as is. You'll probably need to implement some sort of task that cleans up expired cookies periodically, and so on.
Do not fear the cookie. It's just a header (with browser-imparted magical powers).
Some small percentage of the time, we see a flow like this, deducing from looking at server logs (I have not been able to reproduce this case with any browser):
At time A, client hits our page:
with no cookies
gets back a response with a Set-Cookie HTTP response header that gives them a session id of B
body has JS to fire an AJAX request /ajax/foo.
At time A + 1 second, client hits us with the AJAX request to /ajax/foo
the referrer is set to the page in step 1 that fired the AJAX, as expected
with no cookies - why?
gets back a response with a Set-Cookie header that gives them a session id of C (expected, since they didn't send us a cookie)
At some time slightly later, all of the client requests are sending either session id B or C - so the problem is not that the browser has cookies turned off.
This seems to be essentially a race condition -- the main page request and the AJAX request come in together very close in time, both with no cookies, and there is a race to set the cookie. One wins and one loses.
What is puzzling to me is how could this happen? My assumption is that by time the browser has read enough of the response to know that it needs to fire an AJAX request, it has already received the HTTP response headers and thus the Set-Cookie response header. So it seems to me that the client would always send back the cookie that we set in the page that fired the AJAX request. I just don't see how this could happen unless the browser is not promptly processing the Set-Cookie response.
Like I said, I can't reproduce this in Firefox, Safari, or Chrome, but we do see it several times a day.
There is a new feature in google chrome that could cause this misbehavior. It is called prerender.
Prerendering is an experimental feature in Chrome (versions 13 and up)
that can take hints from a site’s author to speed up the browsing
experience of users. A site author includes an element in HTML that
instructs Chrome to fetch and render an additional page in advance of
the user actually clicking on it.
Even if you do not proactively trigger prerendering yourself, it is
still possible that another site will instruct Chrome to prerender
your site. If your page is being prerendered, it may or may not ever
be shown to the user (depending on if the user clicks the link). In
the vast majority of cases, you shouldn’t have to do anything special
to handle your page being prerendered—it should just work.
For more information read: http://code.google.com/chrome/whitepapers/prerender.html
Edit:
You could trigger prerender on your page with: http://prerender-test.appspot.com/
a) Does the cookie have an expiration time?
b) If so, have you tried to reproduce it by setting the computer's clock back or forward by more than the TTL of the cookie? (I mean the clock of the computer running the browser, obviously; not the server running the app ... which should be a separate computer whose clock is set accurately.)
I've seen this as well; it seems to be triggered by users with screwed up system clocks. The cookie was sent with an expiration date that, from the browser's perspective, was already past.
my question upfront is:
When changing from http to https: How do I enforce on Tomcat that the value of the JSESSIONID / (i.e. the session cookie) gets changed?
Here's my situation:
I assume we are having a potential security issue in our application and wonder how to fix it.
We run a JSF1.2 / Seam2 application inside of a Tomcat 6.x and force the usage of session cookies (no sessionid in URLs).
We allow http access, but when a user logs in we switch to https and stay on https.
We also do have a Filter that adds 'secure' to the cookie whenever the request is coming through https to ensure that the session cannot go back to http.
(somehow I thought Tomcat would do that automatically)
I noticed that the JSESSIONID doesn't change when switching between http and https.
This suggests to me that an attacker could potentially spy out the session cookie through http and then hijack the session.
So how can I tell Tomcat to use a different JSESSIONID when changing to https?
(Or if thats the default behavior: What could lead to this not happening anymore?)
Thanks for any hints/ideas!
some time (years actually) I posted this filter here that we use to renew the session ID after the login:
https://issues.jboss.org/browse/JBSEAM-2450
We call newSession() just after a login to mark the session-ID to be renewed on the next GET request (POST requests don't work well due to the restore of the view state, but the POST/REDIRECT/GET with Seam will issue GETs quite often).
You might want put it into your filter -- or you just mark your session to be refreshed in the next GET request. Just make sure that you don't renew your session when processing a JSF POST request.
Someone else also provided a Tomcat Valve to solve this
Best regards,
Alexander.