Firstly, cookieless sessions are a potential security risk, since it makes it does make is potentially easy for session ids to be stolen.

But having said that - the only way for an application to support cookieless sessions correctly is for the application to be designed from the ground up with that methodology in mind - one of the main reasons for doing this is the use of absolute paths.

For cookieless sessions to work every url on your site that contains a link needs to have the current session cookie id embedded into it.

So instead of:

 <a href="/home.aspx">Go to Home Page</a>  

each link has to look like:

 <a href="/(12345678910)/home/aspx">Go to Home Page</a> where (12345678910) is the current session id.

Any link that does NOT have the session id in it will force the start of a new session
 - now since for example dnnmenu generates a huge number of url's on the fly it would need to be including the session id in every one as it went.

The same would go for every link generated/selected or entered into every module on the site.

Now having said all this - are there any ways to deal with this.

There are a couple of possible solutions that I could think of: 

1. A skin object or some such that iterates thru the asp.net object collected just before the session state is created and attempts to update every URL.
this would be process intensive requiring a walk of the full page tree and a good understanding of the types of places where the url's are stored.
and the could still be some potential issues

2. an outbound httphandler that intercepts the rendered html stream and injects the session element into each url
 - this may however cause problems with viewstate

3. a javascript client side function that iterates thru the html markup when it gets to the browser and injects the session element into each url
- could have some performance issue due to the large number of urls the dnnmenu creates.

Of the solutions above - item 3. would be a way to get the urls sorted since once the page is in the browser = but if there were any urls being dynamically generated in jquery or javascript routines this could potentially cause a new set of issues.

And finally for all of these - have no idea what sort of havoc all this would have on the dnn friendly rewriter.


As for how to stop a user opening 2 tabs - sorry you are out of luck there.