Hi guys,
We're currently using .Net Core MVC + jQuery version 6.9.
We host our application in Azure and when we swap our application slots between staging and production, all current users on the system get kicked and are forced to log in again, due to a loss of session.
We've done some research into session management with .Net and Azure, and there seem to be a few options, but we also noticed that in the .Net Zero Documentation it says:
ASP.NET Boilerplate provides an IAbpSession interface to obtain the current user and tenant without using ASP.NET's Session.
Does this mean that any standard methods for managing session will not work with .Net Zero? If not, has anyone implemented an alternative?
If this isn't an issue, then the three main methods that we've come across so far are these:
1.Table Storage 2.SQL Azure 3.Windows Azure Caching (using Redis)
Has anyone implemeneted one of these session management techniquies? Where there any hidden pitfalls or traps that you encountered? Alternatively, does anyone from the .Net Zero team have feedback/suggestions on this matter?
Thanks,
David
3 Answer(s)
-
0
we swap our application slots between staging and production
Specifically how to do it?
If the domain name of the staging and production environments is different and not configured, the cookie will also be invalid. The user login status will be invalid.
-
0
When we swap the slots, the domain names don't change - the clients using the production site/domain would still be using the same site/domain after we swap, it's just that the code in that environment has changed. So a cookie for domain xyz should still be valid.
We strongly believe that it is server-side session invalidation that causes the users to be logged out and forced to log in again, and that is what we are trying to find a solution for.
-
0
I think it should be the problem caused by the inconsistency of data-protection between the two applications.
Consider a user who signs into the app using cookie authentication. The user signs into the app on one web farm node. If their next request arrives at the same node where they signed in, the app is able to decrypt the authentication cookie and allows access to the app's resource. If their next request arrives at a different node, the app can't decrypt the authentication cookie from the node where the user signed in, and authorization for the requested resource fails.
Please refer to: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/web-farm?view=aspnetcore-2.2#data-protection-and-caching https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-2.2
