>>Using 'cookieless=true' doesn't prevent you from using cookies - just means that the sessionId is in the URL not in a cookie. So if, for example, you wanted to store the user name per session you could use a cookie with the SessionId as the key and 'UserName' as a sub-key.
>
>I was working on this today and started to read this:
>
>http://msdn.microsoft.com/en-us/library/aa479314.aspx
>
>While this can be good, it has some negative effects and this would cause more problems than now.
>
>The main problem we have presently is the following:
>
>1. Users using an old version of our application have the ability to open pick list windows on top of the main browser window. So, this is stateless. This means the user can select another pick list to be opened from the main window and then switch back to the first pick lick, make a selection and cause a logistic problem. That one, however, will go away as soon as those users are moved to the new version. The new version, for those already using it, cannot allow that as only one browser window is in effect at all time.
>
>2. A user uses IE, does a login and has a menu access. He clicks to open a new tab, does a login with a different account, switches back to the first tab and can click on a menu which he shouldn't have access because the browser session is now based on the other login he did and not the first one. So, he can gain access to a menu he shouldn't have. This can be enhanced by verifying the execution of the click on the menu before proceeding to make sure he still has rights to it. But, the same would apply for all options so this is really a problem.
>
>Situation #1 is the one that is more problematic and would go away when all users are moved to the new version. This is a matter of a few months.
>
>Situation #2 is a real problem. It doesn't happen that much but sometimes, we are investigating on issues, and they are really difficult to find because users are playing with two instances of the browsers, thinking they can do two logins and each instance would remember its own login where it isn't the case. So, when they switch back to the first instance, they are in fact on the second account.
>
>The "Thumbs Down" section of that page is really scary. First, because, this is broadcasted in the URL so anyone can see it or grab it by any means and use it after taking over the session. The URL syntax that this generates is also something that changes the way the URL are being recognized and managed. It seems to me that implementing this approach is more problematic than staying like actual. But, maybe I am missing something.

How about a cookieless session over https ?

Wish the SecureSessionModule here http://msdn.microsoft.com/en-gb/magazine/cc300500.aspx was more readable - can't work out what it is doing.....