views:

720

answers:

2

In ASP.NET a session is for the browser. But how can I create a session for a tab?

+1  A: 

The session cookie is held in volatile storage accessible to that instance of the browser. You would need a browser that supported the concept you are after, no such browser exists to my knowledge.

In ASP.NET you can maintain a session without using a session cookie, its real ugly and I wouldn't recommend it but it may be a way for you acheive your goal.

AnthonyWJones
@Downvoter: Please explain?
AnthonyWJones
+1  A: 

Use the following:

<configuration>
  <system.web>
    <sessionState cookieless="true"
      regenerateExpiredSessionId="true" />
  </system.web>
</configuration>

And a citation from MSDN:

ASP.NET maintains cookieless session state by automatically inserting a unique session ID into the page's URL. For example, the following URL has been modified by ASP.NET to include the unique session ID lit3py55t21z5v55vlm25s55:

http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx

When ASP.NET sends a page to the browser, it modifies any links in the page that use an application-relative path by embedding a session ID value in the links. (Links with absolute paths are not modified.) Session state is maintained as long as the user clicks links that have been modified in this manner. However, if the client rewrites a URL that is supplied by the application, ASP.NET may not be able to resolve the session ID and associate the request with an existing session. In that case, a new session is started for the request.

So the all you need to open a new session for new tab is to open an url without session identifier.
EDIT:
And as other users mentioned, you should take care of this 'kung-fu'. If you are storing user-sensitive information in session - please, secure your authentification cookies.

EDIT2: And be aware that when you'll use session key in url the users can copy it and send to some friends. And this user and his friends will share the single session (this will be a great feature! :)). To avoid this you can do the following:
1. Add somehow association to user (user's profile, store in database) in onSessionStart method and check it on BeginRequest.
2. Check referrer and create new session (redirect to sessionless url) when referrer is empty or it not equals to the current domain (but be aware that referrer can be manually set)
3. Rewrite generation of session ID and associate it with the username and ip/mac (xor or something like this). And verify this on the stage when session is picked up.
4. Something else to make this session key valid only to current user.

zihotki
Using cookieless sessions introduces a really terrible security problem, I don't think it should ever be used.
meandmycode
Not very easy, a lot harder.. cookieless sessions damage the urls of the site, and worse clients don't realize that if they copy and paste the url.. they are giving away their session.. something that doesn't happen with normal sessions.. as users can't ignorantly give away their cookie values.. the most likely causes of stealing sessions is via XSS on the site.
meandmycode
Is this hard to add somehow association to user in onSessionStart method? Is this hard to check referrer and create new session when referrer is empty or it not equals to the current domain? Is this hard to rewrite generation of session ID and map it to the username and ip/mac? There are a LOT of ways to fix cases when users copy and give the link to somebody. We always can add a big shiny button "copy current url into buffer". About XSS, it seems to me that you know a little about it. When you have XSS hole then ALL cookies can be stealed. You should take much more care about auth cookie.
zihotki
Uh, I said 'the most likely cause of stealing sessions is via XSS on the site'.. perhaps you should read.. and yea I'll tell my users that it is their fault when their account is compromized because they didn't click 'copy url' but instead 'stupidly' just copied the url in their browser.. clearly you voted down my suggestion because you have a twisted sense of security in http.. and just to make it clear: im well aware cookies aren't safe, but they are a hell of a lot safer than urls.. and generally compromized by XSS, of which XSS attacks can do FAR worse things than steal cookies..
meandmycode
@zihotki: You are correct. Like I said though, its ugly.
AnthonyWJones
@AnthonyWJones, but this is the best way to do this. Btw, ASP.NET WebForms and VB are ugly too, but who cares?
zihotki