Are per-session cookies switched on?

[Craig Watts]

Im aware that navigator.cookiesEnabled can be used to find out if a user has their normal cookies enabled or disabled.

I need to know if it is possible to find out if per-session cookies are switched on (cookies that are destroyed when the browser is closed). You can see these listed in the security options in IE (in the cookies section). I need to find out if per-session cookies are switched off so I can tell a user they must switch them on in order for them to be able to access a site.

Any help would be great, even a 'no sorry Im not sure'

Cheers

[joh6nn]

i'm not familiar with such a setting in IE, and i couldn't find it just now when i looked. to the best of my knowledge, there's no difference between "normal" cookies and session cookies, except in their expiration dates, so that having cookies enabled, means that all cookies are enabled.

[ShriekForth]

I came across this problem a few weeks ago, and never did find a way to tell. IE does allow for the two cookies to be turned off independently. Testing for the browser cookie was the first test I did, but one of our testers get it in his head to turn of the per-session based cookie. With no session-cookie/ID available, the user never did get logged into the site.

If they did not have the browser cookies available, the <noscript> would take care of that, but if they enabled those, and removed the session cookie, the data posted would attempt to start a process to get a user into session, the sessionID was never saved on the client and passed in the header so they ended up failing before they got logged in.

In IE 5.5 at least, you can find it under security/custom levels/cookies. There are two cookies "Allow Cookies that are stored on your computer" and "Allow per-session cookies (not stored)". The session cookies store the sessionID in a cookie so that it does not have to be passed on each URL. There is a way to do that with weblogic, I can't recall what it is now, but it will pass the session ID on each link. Looks ugly, but it works. There might be another way as well with another app or web server. I know we worked around it on some of our initial WAP/WML implementations. We passed it as a hidden field in a form.

I don't know how persistent you want the session to be, but you could place the session ID into the URL or form on each page. Not a nice task, but most server side languages should support accessing the current session ID. Something to look at, and think about anyway.

ShriekForth

[brothercake]

But isn't that all the same? As far as getting a script to read cookie data, a permanent cookie is exactly the same as a session-cookie. Unless you're using "sessions" .. but that's something else entirely.

The simplest way I know of to check for cookie support is like this:

1 - set a cookie with a test value
2 - immediately try to read the test value out of that cookie, then delete it

If step 2 returns a value, you have cookie support; otherwise you don't

Once you've established cookie support, you can set a cookie. If the user has session cookies enabled, but not permanent cookies, then the difference is that when they close the session and return, there will be no persistence. But within that session, it will work.

[ShriekForth]

A session cookie is never written to the clients machine, it stays in memory, and is passed with each http request to the server.

In my case (banking) that sessionid is used by the servlet to identify the session information on the app server. Without this being used/passed on each request we cannot store the users information. Without this we do not know if the user is autenticated. It would be too time consuming to go out and retrieve all the users accounts, and data from the banks internal systems. So we store basic information in session, and update/add to it as nessesary.

When this is turned off, it creates a problem unless we force the sessionid onto every url. Even if it's the same browser instance they will not make it to the next page because we cannot match user with session information.

ShriekForth