Possible to emulate the death of a session-cookie in a cookieless site?

I'm building a site/app which will be displayed in an iframe. I have done it loads of times before, and it has caused me loads of problems in the past... The main problem is crossdomain cookies being blocked.

I know it is a matter of using the same root domain name and setting document.domain. But considering the lovely new EU cookie legislation (omg they are lame) and the general direction browsers are heading with respect to privacy and security, using session-cookies in iframes will probably become more and more troublesome. So in order to futureproof the site a little, I would prefer to implement it without using cookies at all.

The implementation I have so far simply sets a query string value, which is passed on to all pages. I guess this is kind of the same as ASP.NETs cookieless session feature. However this has the implication that if someone uses a public computer, another person using it a moment later can find their URL (including session ID) and continue their session. Since this site deals with sensitive data that is not acceptable. The ASP.NET cookieless feature suffers from the same loophole (which makes me a bit pessimistic about finding a solution).

I'm developing in .NET but this must be a generic issue for all environments.

Short version:

Does anyone know how to maintain session state in a cookieless site running inside an iframe (perhaps some best practices as well). It is imperative that when the user closes his browser the session must be effectively killed, 开发者_Python百科so no info is disclosed by the browser history list - just as it would with a normal session-cookie.

Possible solution

I'm considering something along these lines. But it is far from optimal.

1. The page continouesly makes a keep-alive ajax-request to the server
2. The server updates a timestamp with last keep-alive invocation for the ID stored in the query string
3. If the keepalive timestamp gets more than say 10 seconds old, the data related to the ID is killed, and the user will receive a "session timed out - please start over" message if they revisit the URL with the now dead ID.

I know it is a matter of using the same root domain name and setting document.domain

No - using a single sign-on is a much more sensible approach (still uses cookies though)

But considering the lovely new EU cookie legislation (omg they are lame)

Go read it, particularly notes 25 and 26. There are a huge number of get-out clauses. It's still good practice and service to provide a page detailing privacy information, and this may suffice or even exceed any obligations under the act. But do design your site to detect where the user is not accepting cookies and make it respond appropriately.

I would prefer to implement it without using cookies at all.

Trust me, you don't. You've mentioned propagating session ids via the URL - this is the only thing approximating a substitute, but in addition to the security issues you've mentioned it is also very fragile and restrictive (e.g. for your ajax calls, you're going to have to parse the current url to extract the session id and insert it into the subsequent request).

Note that all this pre-supposes that your site requires state to be retained serverside (which is somewhat implied by the mention of sensitive data and therefore authentication).