1
votes

I'm storing a token in a session variable. I launch a report that needs this token in a new ASPX page by using the javascript windows.open function. When this new page loads the HttpContext.Current.Session is null.

I have gotten around this by passing the token in the query string but activity in this window needs to keep the session of the parent window active and I'm not sure what the session object being null means for this scenario.

Any idea why the HttpContext.Current.Session object would be null by using window.open from javascript?

EDIT: I will add that this is a basic System.Web.UI.Page stored in a SharePoint library and the window.open function is called from a webpart. I'm thinking that this page may need to inherit from a base class to share the right context.

UPDATE: I've narrowed down that this is related to SharePoint. I moved the code that accesses the Session object into a web part. The web part works fine if put in a standard web part page but I have it added to a minimal page that only contains a ScriptManager, SPWebPartManager and a WebPartZone. The code runs but the session object is again null. My minimal page is missing something that makes the Session object available.

SOLVED: My minimal ASPX page needed to implement the IRequiresSessionState interface. After that the Session object is there.

I'm going to give the cred to Andrey since he offered the most useful information.

3
I took this page and moved it from the SharePoint library to the _layouts directory and inherited from LayoutsPageBase but it had no affect. The HttpSessionState object from the HttpContext.Current is null. - webwires
As I mentioned in my answer, session cookie is not persistent so it is not shared between different browser windows. You have to explicitly pass session id to the new window, whether as a persistent cookie you create or as a part of the url. There is no other way. - Andrey
We are already using persistent cookies. Our SharePoint site uses FBA and we required cookie persistence for Office integration. I have been able to verify that this is SharePoint related. I turned the page into a minimal web part page and moved the Session access to a web part. If the web part is put in a standard sharepoint web part page it works. If I use it in the minimal it fails. I'm missing something in the page that makes the session available. - webwires

3 Answers

2
votes

Technically, it's a different connection to the web site, that's why it's a different session. It's probably better to use Application cache instead of session if you want different windows to utilize the same session storage.

UPDATE: What you can do if you want to stick to using session state, is to write the session ID to a persistent cookie, this way the child window's call to the server will carry it along and you can retrieve SessionID from that cookie. IMPORTANT: Make sure you encrypt session ID ebfore putting into teh cookie to avoid session hijacking.

1
votes

window.open() should keep the same session id

window.open() clears session

make sure that the url you pass to the open() method is relative or the same domain name

0
votes

I assume you are using IIS 6 or later.


Lets say you have 2 different websites:

http://site1.yourdomain.com
http://site2.yourdomain.com

2 things can happen

  1. Both sites run under the same Application Pool: Session should be the same for both sites.

    note: Internet Explorer prior to version 8 gets assigned different session if the newest window is not originated from the currently open window. Starting on version 8 all windows accessing the same Application Pool share the same version regardless the origin of the window.

  2. Sites run under different Application Pools in IIS: Not even dreaming you can share the same session for both windows

If the website is the same for both windows you shouldn't have any problem sharing session between two windows, even with any version of Internet Explorer since the second window is originating from the first one by calling window.open() method.