Reputation: 14937
I'm trying to publish my web app from VS without no downtime. If you search in Google, you find the official documentation speaking about using slots and do a swap later.
This is a good approach, but I have other problem when I do the swap, logins are lost (look this question: link).
Relevant information in the link:
Session is not linked to Authentication, you're attempting to solve it in the wrong way.
All forms authentication tickets and cookies are encrypted and signed using the data protection layer. The problem you are encountering is due to the encryption keys not being saved, and applications being isolated from each other.
How can I do that? In AWS I had rolling updates...
For more information, I'm using ASP.NET Core with Identity 3.0
Thanks!!
Upvotes: 1
Views: 381
Reputation: 937
I found a fork for aspnet core 1.0, for those interested:
https://github.com/prajaybasu/DataProtection.Azure/tree/dev/DataProtection.Azure
just like the other one, it stores encryption keys on an azure storage account. It completely solved my problem.
Starting from blowdart's solution I solved my issue, so thanks.
Andrea
Upvotes: 0
Reputation: 56550
What you're seeing is an azure limitation right now. While Azure Web Sites will share the key ring it sees swap slots as separate applications.
There are a couple of things to try.
First, set a common application name. This will help because every application which shares the keyring is isolated by default; but if they share the application name they can share keys
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection();
services.ConfigureDataProtection(configure =>
{
configure.SetApplicationName("my application");
});
}
If that's not enough for azure (I am honestly unsure if hot swaps end up using Azure Web App's shared key folder) you can combine that with using Azure Data Tables for storing the encryption keys - https://github.com/GrabYourPitchforks/DataProtection.Azure/tree/dev
Between those two it should get the encryption keys used to protect identity cookies shared between your apps.
Upvotes: 2
Reputation: 2057
Are you using in-memory session state?
The problem with 'logins' being 'lost' is an architecture issue, not an issue with updating your web app.
Use something like RedisCache for session state. Not only will it persist when you update your application, but it will handle load-balancing on multiple server instances. As it sits you'll probably have this issue when you scale out to more than one server, in addition to when you update your app.
Upvotes: -1