Passing session data between ASP.NET Applications

asp.netsessionweb-applications

We have several ASP.NET applications deployed to a few servers. Is there a standard way to reuse session data or some other method to not require users to log in to the next application when moving from application to application if they've already authenticated? I'm hoping there's a best practices way of doing this that you guys know about. I feel like there should be something easy that I'm missing.

Thanks.

Edit: To be be more clear, the main info in the session that I'd like to pass is the authenticated userid, but possibly some other session variables as well.

Best Answer

you could implement a single-signon strategy for your applications.

http://aspalliance.com/1545_Understanding_Single_SignOn_in_ASPNET_20.all

http://blah.winsmarts.com/2006/05/19/aspnet-20-implementing-single-sign-on-sso-with-membership-api.aspx

http://johndyer.name/post/2005/12/Single-SignOn-with-ASPNET-Membership-and-WebServices.aspx

http://msdn.microsoft.com/en-us/library/ms972971.aspx

Related Solutions

ASP.NET Session Timeout Testing

Decrease the timeout

The easiest and most non-intrusive way to test this is probably to just decrease the timeout to a fairly small number, such as 3 or 5 minutes. This way you can pause for a few minutes to simulate a longer pause without worrying about application restarts or special reset code having any affect on your test results.

You can modify the session state timeout in a few locations - globally (in the web.config located in the config folder for the applicable .NET framework version), or just for your application.

To modify the timeout just for your application, you can add the following to your application's web.config:

  <system.web>
    <sessionState timeout="60" /> 
  ...

Alternatively, you can also modify this same setting for your application through an IIS configuration dialog (I believe you still need to have a web.config defined for your application though, otherwise Edit Configuration will be disabled).

To access this, right-click on your web application in IIS, and navigate to Properties | ASP.NET tab | Edit Configuration | State Management tab | Session timeout (minutes).

Note that you can also manipulate this setting through code - if this is already being done, than the setting in the web.config file will effectively be ignored and you will need to use another technique.

Call Session.Abandon()

A slightly more intrusive technique than setting a low timeout would be to call Session.Abandon(). Be sure to call this from a page separate from your application though, as the session isn't actually ended until all script commands on the current page are processed.

My understanding is that this would be a fairly clean way to test session timeouts without actually waiting for them.

Force an application restart

In a default configuration of session state, you can simulate a session timeout by blowing away the sessions entirely by causing the application to restart. This can be done several ways, a few of which are listed below:

Recycle the app pool through
- the IIS MMC snap-in
- the command-line (iisapp /a AppPoolID /r)
- modifying web.config, global.asax, or a dll in the bin directory
Restart IIS through
- the IIS MMC snap-in
- services.msc and restarting the IIS Admin service
- the command-line (iisreset)

When I mention "default configuration", I mean a web application that is configured to use "InProc" session state mode. There are others modes that can actually maintain session state even if the web application is restarted (StateServer, SQLServer, Custom).

Tamper with the state tracking mechanism

Assuming your web application isn't configured with a "cookie-less" mode (by default, cookies will be used), you could remove the cookie containing the session ID from the client browser.

However, my understanding is that this isn't really simulating a time-out, as the server will still be aware of the session, it just won't see anyone using it. The request without a session ID will simply be treated as an unseen request in need of a new session, which may or may not be what you want to test.

.net – ASP.NET Web Site or ASP.NET Web Application

Website:

The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.

If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name, which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.

Web Application:

The Web Application Project was created as an add-in and now exists as part of SP 1 for Visual Studio 2005. The main differences are the Web Application Project was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build time. To update the project, it must be recompiled and the DLL file published for changes to occur.

Another nice feature of the Web Application project is it's much easier to exclude files from the project view. In the Web Site project, each file that you exclude is renamed with an excluded keyword in the filename. In the Web Application Project, the project just keeps track of which files to include/exclude from the project view without renaming them, making things much tidier.

Reference

The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:

You need to migrate large Visual Studio .NET 2003 applications to VS 2005? use the Web Application project.

You want to open and edit any directory as a Web project without creating a project file? use Web Site project.

You need to add pre-build and post-build steps during compilation? use Web Application project.

You need to build a Web application using multiple Web projects? use the Web Application project.

You want to generate one assembly for each page? use the Web Site project.

You prefer dynamic compilation and working on pages without building entire site on each page view? use Web Site project.

You prefer single-page code model to code-behind model? use Web Site project.

Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.