I have two ASP.NET applications using Forms Authentication and Single Sign On and I would like to persist Session variables between them.
Upon testing, I cant seem to get the Session variables to be read from the other application. Both apps are on the same domain (app1.domain.com & app2.domain.com) and I have set up my config (a.f.a.i.k.) correctly to reflect this.
I have noticed that when testing on the release server the session id is different even when using tab pages on the same browser (I thought they would be the same!), yet debugging on my local IIS the session id is the same (and I still cant read session variables across sub-domains).
Anyone got any pointers to what I may have missed?
Best Regards
By default, SessionState mode is InProc which means Session State data is stored in each AppDomain's memory. AppDomains are isolated, and they do not share SessionState.
You need SQLServer or StateServer as SessionState mode.
Related
I'm using ASP.NET 5 Session in StateServer mode with a session state service running on a different machine. When all is working fine in the app, certain session objects are able to be accessed from the Session. However, when I restart the app, it appears that the user's session still exists, but certain objects throw an (de)serialization error when trying to get them from session. This leads me to believe that most of the time the session data is getting pulled from a local cache that doesn't serialize/deserialize the objects like the StateServer does... and then when the app restarts the local cache is lost, and so the objects have to get pulled from the StateServer, which then has problems deserializaing certain objects.
Can anyone confirm my hunch about Session caching when using StateServer mode in asp.net 5?
EDIT: I think I found the answer here:
I was actually surprised to see the behavior exactly the same as with
InProc objects. Even though objects serialize ASP. Net tracks objects
locally and writes out any changes out to the stateserver.
I am working on a MVC 3 application that will be hosted in a web-farm with a multi-worker process setup. There are about a dozen variables that are being stored in Session but are getting lost due to the IIS setup.
By getting lost I mean that when the Logon process succeeds I see through logging that I have set the Session variables but then after the Redirect action and on the landing Controller Action the Session variables are often empty. I'm not sure if this is related but this is in a HTTPS.
We are looking at the possibility of moving our user-specific settings that are stored in Session out to some other mechanism but there is one variable that I won't be able to do that with. Given the above deployment environment I have the following questions.
Are cookies my only (best?) alternative to storing Session variables for user-specific settings?
If so is there a secure mechanism for writing cookies so they cannot be manipulated and can still be read in a multi-server environment?
As I understand it System.Runtime.Caching suffers from the same problem when ran in the above IIS configuration. Is that true?
Are cookies my only (best?) alternative to storing Session variables
for user-specific settings?
No - they are about the worst possible approach. Three reasons that come to mind:
They can be manipulated.
They travel with every request from client to server - inefficient.
They will add more complications to your implementation since you'll have to start thinking about securing them in different ways.
If so is there a secure mechanism for writing cookies so they cannot
be manipulated and can still be read in a multi-server environment?
See answer above.
As I understand it System.Runtime.Caching suffers from the same
problem when ran in the above IIS configuration. Is that true?
True. You should be using any of the State Providers that are out of proc. You can either use Sql Server to store session data -provided your objects are serializable, obviously- or the State server mode mode="stateserver"
Read here for more details
The ASP.NET SQL SessionState provider seems excessive for my requirements. SQL Server has to be 'configured' to support it and I have questions about how optimized it is (i.e. is there one db hit to fetch the whole session or one for every session item requested?).
I think I could implement a custom solution very easily that I would understand and easily redeploy to other projects. Is there something fundamental I haven't considered here and an obvious reason why the built in SessionState handler is the 'best' way to go?
Just to clarify, our applications run on single servers at the moment. My main motivation for doing this is to enable Session to persist across IIS restarts and therefore provide more reliability for users.
you could use StateServer mode.
StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool.
Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
more info at http://msdn.microsoft.com/en-us/library/ms178586.aspx
It takes just minutes to setup SQL session state server (assuming you have SQL server already running). I can't imagine that you can write anything in less time than it would take to at least try out what already exists and is free and supported by MS.
A proven, built-in/off-the-shelf solution is always better place to start than custom. You may still end up with a custom solution, but don't pick it because you didn't bother to test what is already available to you.
I have a Session variable holding a boolean value. It works just fine in on my development machine and my development server. When I move my code to production it no longer works.
It doesn't matter if I'm using a cookieless session either, so it can't be a timeout issue or a cookie issue.
It happens on all modern browsers.
I'm using the Response.Redirect overload where the endResponse parameter is set to false.
The machine is not in a webfarm.
Session storage is to my knowledge InProc, it is not in SQL Server.
The session variable holds the boolean variable at least once, because I print it out in a label on the page following my setting of the variable and the Response.Redirect. But afterward it gets set back to NULL, it does not do this in development.
Its all the same code, but the IIS settings might be different on production, I just don't know where to look.
Yikes this could turn into a nightmare of a problem.
Do you have a completely independent and clean machine you can deploy your project to and see if you can replicate the behavior on another IIS that is in a known state?
Do you have the ability to just reimage the server?
Check settings on the server's applicationHost.config and machine.config to see if the session is set to use InProc or Sql based session persistence. If it's sql based is the database screwed up?
Assuming the session is InProc like you expect, is IIS reseting constantly? Do trace logging of your application start and end events.
Is your application being called by an iframe or somethnig? I had this problem once, Icouldn't find a solution, I'm still looking for one
I solved this problem integrating the application in the same server as the application who loaded our app in an iframe.
Hope it helps you.
I was told this works, but...
I guess I'm just not getting this, it seems there's a hidden step I may be missing, can anyone correct this or point out my mistake? Thanks.
I have a blank solution:
- inside is two .net 2.0 web applications
1) webapp1
2) webapp2
I want them to share the same session data.
My page setups:
Application 1:
Session("value") = "this is the value"
Application 2:
If Not (Session("value") Is Nothing) Then
value = Session("value").ToString()
End If
My thought process:
1) go to services, turn on the asp.net state service
2) open the web configs in both projects: set the
< machineKey
validationKey="BFE2909A81903BB303D738555FEBC0C63EB39636F6FEFBF8005936CBF5FEB88CE327BDBD56AD70749F502FF9D5DECF575C13FA2D17CA8870ED21AD935635D4CC"
decryptionKey="2A86BF77049EBA3A2FA786325592D640D5ACD17AF8FFAC04" validation="SHA1" />
< sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424"
cookieless="false" timeout="20"/>
in both sites.
3) compile and test the site
4) become disappointed because it does not work. I never see the session from the second webapp.
You cannot share sessions between different ASP.NET applications without some custom code. What you did in web.config was to use an out of process sessions, which means that data will no longer reside into memory but into the memory of a dedicated machine. This is useful for server farms and it uses the ApplicationName to know which application the session belongs to. So basically your applications need to have the same name if you want them to share sessions. There are some dirty workarounds though.
Why do you want to share Sessions between applications? ASP.NET Session is not designed to do that.
Your proposed solution of using the same ASP.NET State Server does not work because your user will simply get 2 different session tokens, even if they use your 2 applications concurrently from the same machine, and same browser. You need to consider how Session works to understand why this is.
From MSDN:
ASP.NET session state enables you to store and retrieve values for a
user as the user navigates ASP.NET pages in a Web application. HTTP is
a stateless protocol. This means that a Web server treats each HTTP
request for a page as an independent request. The server retains no
knowledge of variable values that were used during previous requests.
ASP.NET session state identifies requests from the same browser during
a limited time window as a session, and provides a way to persist
variable values for the duration of that session.
ASP.NET Session is a metaphor for a user's current interaction with one ASP.NET application. It exists in ASP.NET to give us a place to store temporary state data between the various page requests that a user makes while using your application.
If your applications are very closely related, e.g. the user uses both at the same time, or almost the same time, you could consider merging them into a single ASP.NET application. You could deploy them into different Virtual Directories to maintain some degree of logical separation, but use only one Application in IIS.
If your applications are not that closely related, perhaps they should be sharing the same database as a means to exchange data, or using an API e.g. based on Web Services to exchange information.
They will share session data if they are in the same app pool and the session mode is set to inproc. The way that stateserver and sqlstate work is they use the root of your web address as logical boundaries.
Eg if they are both hosted on the same address and port (or 'site' in iis) but in different sibfolders then they should share session I think.
Additionally both apps must run on the same domain so that user browser use one cookie to store session id.