Can ASP.NET applications in a common application pool share session information if they are in separate threads in a single worker process? One of my applications is having issues related to not having any of the session information it needs from the other application, but I used Trace.axd to confirm that requests to each application are using the same session identifier.
I resolved the issues we were experiencing by making our applications "cookieless".
I updated the web.config file for the applications as follows:
<!--sessionState mode="InProc" cookieless="false" timeout="30" /-->
<sessionState mode="InProc" cookieless="true" timeout="30" />
If anyone can explain why this works, I would appreciate the education.
Thank you to all who offered suggestions.
ASP.NET session is scoped "within" application if using out-of-the-box session providers, so each application will have its own session even if the session id/key value appears to be the same. But since the requests to each application are using the same session identifier value, you appear to be well set to implement a custom SessionStateStoreProvider that can store/retrieve data using this identifier across both applications.
You could also have a look at Sharing sessions across applications using the ASP.NET Session State Service, but since this approach involves modifying the workings of the stock SQL session store provider, you'd risk spillover effects on other sites/applications.
I thik it could be helpfull Sharing Aspnet Session across different domains there's no other way.
you cannot share a session between different domain.
there's another solution that could be pass all data via querystring to the other domain so it can rebuild the right session values.
Personally i will invite you to use encrypted value to be sure that are not visibile if you will choose GET option.
Related
Any advise on this one would be greatly appreciated, I've been researching all morning and I'm still scratching my head. I started at a new company a few weeks ago, where I'm the only .NET developer as the development was originally done by an outsourcing company and I've been asked to research.
My knowledge of the existing system is extremely limited but from what I can gather the situation is as follows.
We would like to enable sticky sessions on an asp.net web site. From my research I have gathered, I need to do the following steps. We are using the ASP.NET State Service
The setup is a load balance server which services two web servers.
Ensure that both web servers have the same machine key.
Ensure that the websites have been precompiled before deployment. For serialisation of objects by ASP.NET State Service.
Ensure that the application path on the iis metabase is identical on both web servers.
I bit of knowledge I'm lacking is where are the sessions are stored. Are the sessions stored on the load balancer, can they be stored on the load balancer? From what I've read they are stored by the ASP.NET State Service, should the service be running on the load balancer therefore the sessions are stored o the load balancer.
From what I understand the ASP.NET state service runs on each of the web servers and they just talk to each other so that the sessions are stored across both servers. I assume that the way they do this is based on the type of algorithm that is used. Any information would be greatly appreciated.
zeencat, take a look at http://msdn.microsoft.com/en-us/library/ms178586.aspx at the State Server Mode section:
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.
To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed.
From what I understand the ASP.Net state service runs on one server, as a service called ASP.NET state service, both servers will have the same web.config file:
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=SampleStateServer:42424"
cookieless="false"
timeout="20"/>
</system.web>
</configuration>
This way, the session is stored on the server who hosts the service.
Hope it helps,
[]
Also look at using ElastiCache if you are in AWS or Redis if on premise as your ASP.NET session store instead of using sticky sessions. It has more advantages in terms of auto-scaling, load balancing and I would say performance. More info at http://blogs.msdn.com/b/webdev/archive/2014/05/12/announcing-asp-net-session-state-provider-for-redis-preview-release.aspx
Is there a different between session -with mode sqlServer- and Profile ? and who gives us best performance ?
Of course that there is a difference: SQLServer SessionState mode means that everything you put in the ASP.NET Session (not only user profile data) will get serialized and persisted in a SQL Server database, whereas the Profile could be persisted wherever you configure it to. There are out-of-the-box profile providers that persist the information in SQL Server. Definitely go with a profile. Don't use ASP.NET Sessions at all. The best ASP.NET SessionState mode is the following:
<sessionState mode="Off" />
I'd recommend you to always use it. It will make your web application stateless, the way they should be.
I need your help to sort out one problem with session timeout in my application which are hosted on Azure platform.
I have developed web application in asp.net and make login functionality with session and put following code maintain timeout period for session like
<sessionState mode="InProc" timeout="20"></sessionState>
It working fine on local system but when i will tested it with live URL on Azure platform it will signout frequently (session expired).
Can any one please suggest me how can i resolve this issues?
Thanks
Arun.
Are you running more than one WebRole instance? Remember, "InProc" session-state will not be shared across multiple web-role instances. In fact, InProc session state is "evil" in the cloud world, will not work for any deployments with more than 1 instance running. You really want to use another provider, like Session provider for AppFabric Cache
Are you sure the session is expiring? If you are using ASP.NET forms authentication there is another timeout to consider (here I have set it to 180 mins)
<authentication mode="Forms">
<forms loginUrl="Login/" timeout="180"/>
</authentication>
If you do have multiple instances Igorek is right - the session will not be shared.
Please see how-does-microsoft-azure-handle-session-state/1023125#1023125
or refer to the Azure SDK for more information.
I'm working on a multi-tenant ASP.NET MVC application.
So far we have been using HttpContext to store a few objects for the request (technically partitioned by tenant).
However, we will need to use TempData (uses Session) and set authentication cookies.
Our spec:
A tenant can have multiple urls (tenant1.myapp.com or mycustomdomain.com)
Authentication cookies should NOT be shared by tenants
Ideally, a tenant's authentication cookie should be shared by any one of their urls
Is Session domain aware? It seems to be.
Can I set multiple domains on an authentication cookie?
Advice on anything else that may catch me out would be appreciated. Really I just need to understand what needs to be partitioned for each tenant (up to now I've partitioned the file system, database and cache per tenant).
Thanks
Ben
Is Session domain aware?
By default Session is tracked by cookies and because cookies are restricted to the same domain the session is not only domain aware but also application-aware meaning that if you have two applications on the same domain they won't share session.
Can I set multiple domains on an authentication cookie?
No. Cookies cannot be shared between domains. But contrary to sessions you can share them among multiple applications on the same domain (by setting the domain attribute to the top level domain in the <forms> tag in web.config). This is what allows to achieve single sign on between applications on the same domain. If you wanted to achieve single sign on between applications on different domains you will need different approach.
you may want to look into Session Partitioning.
<configuration>
<system.web>
<sessionState
mode="StateServer"
partitionResolverType=
"IndustryStrengthSessionState.PartitionResolver" />
</system.web>
</configuration>
But I don't believe you can share sessions across domains out of the box. You will likely need to add custom session synchronization, where each domains session is linked by a custom algorithm to the same user/tenant etc.
This seems trivial, but I've never had to worry about it before and my Google skills are failing me. How far-reaching is the in-process session bucket for ASP.NET/IIS6, in the sense that you can call Session["whatever"] and get the same value back? Obviously it can't stretch across different servers or application pools (I think). What about different web sites in the same application pool? Can those two see each other's session variables for a user? What about two different virtual directories each with their own web.config?
Thanks!
AFAIK the in-process session has an AppDomain scope, so no, two web applications running in the same pool cannot share an in-process session. Actually the name "in-AppDomain" would be more appropriate.
Obviously it can't stretch across different servers
Sure you can. This MSDN Article has more details.
It can stretch across servers in a farm if the asp.net session is stored in the database.
Perimeter of session is strictly within the one app domain for security reasons
This sounds like you would be better off storing a database value than storing it in a In-Proc session[""]. If you have a state server then the session can be accessed across all machines that use the same state server. In-Proc is just what it says. It's stored In the Process of that single computer.
If you wanted to share Session across applications with a SQL Server backend, there's an article on how to do that.