Session State across ASP.NET apps

[Mark]

Ok, I know that .net inherently does not share session data across asp.net
projects, but is there any decent work around to this.
We already have a big chunk of our application using the asp.net session
object (using state service). I'd like to start breaking out
our functionality into component projects, but I'd like to get this session
issue worked out first.

Any ideas??

I found this article , but it sounds like kind of a pain.

http://www.asp101.com/articles/jayram/sharestate/default.asp

 

[Cowboy]

Set the encrypt and decrypt key to the same value in each web. Then, set the
authentication cookie name (forms auth) to the same name. This will
authenticate the user once for any number of servers. NOTE: If you farm, you
will have to use the same Session Server for all machine (I have not
personally tested this, however).

For session variables, I have yet to have found a solution. Currently, we
persist session vars in a SQL Server database with a timestamp (cleared out
12 hours later). You can then grab the vars in the other app.

I have a theory that placing the applications in the same pool in IIS might
allow sharing of session vars, but have not tested it. Another possibility
is to set up a web service in each app to pass vars to the other app. Since
the web service would recognize the session ID, it could pass back the info.
NOTE: For high security, you would have to encrypt the data before throwing
into the web service return, as a sniffer could get session IDs and query
your web service. I have not tested this yet, either.

As for the article you link to, you can do what the article suggests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck!

* Actually, there is a way to kludge that too, but also not recommended.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Mark]

Yeah, we are already using a central (single) state server for all web
servers in our farm, so I knew about the encrypt decrypt thing for that.

I'm just talking about sharing the session between apps. I'm aware of some
of the hacks you mentioned. I guess I'm just looking for a fairly clean
solution, but it doesn't look like that exists.

thanks .

 

[Guest]

Hi. I've seen this question a bunch of times, and I was interested in it as well, so I tried to pull together everyone's info.


Session state cannot (and should not) be shared because it would be unsecure to do so. In fact, session data isn't completely secure unless you force an SSL connection. Even then, there are issues with older versions of IIS (5.1 and below) where your session state is lost of you browse from an SSL connection to a non-SSL connection, or vice versa.

Using the application object will persist data in the application collection and make it available to all sessions in an app, but there's no way to restrict access.

So, alternatives to sharing session state seem to be:

- Use a SQL database to persist session variables at the end of each session. This allows for access restrictions. You can use the client's cookie as an identifier if you wish. (from 2 seperate posts)

- Implement your own COM component with shared data. Your apps would call that component.

- Use a message queuing system like MSMQ to save or cache data in a "queue which can either
reside locally or on a dedicated server. Any application can read the queue
once it knows the path to the queue - it typically does
You can store the message in any format from text, to
full blown datasets or custom objects. You can think of the msmq as a robust
caching strategy over a network. It's a good approach because the msmq can
be configured to be fail safe (survive reboots), back up messages, provide
confirmation etc. In addition, msmq can be programmed in a line or two, but
it does require the msmq service to installed and running on the machine." (from "How can I share cached data between web clients?")

- Use the solution in the article at http://www.asp101.com/articles/jayram/sharestate/default.asp. However, one poster said, "you can do what the article suggests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck"

- Use remoting.

- Use the Caching Application block.

A good topic on MSDN is "State Management Recommendations" at http://msdn.microsoft.com/library/d...vbcon/html/vbconchoosingserverstateoption.asp. It outlines some of the options above.