Is 1.1.1 data protection incompatible with 1.0?
yellowsix opened this issue · 10 comments
I have had a site running on .net core 1.0 for a while, and I am upgrading it to 1.1.1 now. All is well except that things protected with the Data Protection stuff seem to no longer be compatible... e.g. login cookies. When I tried to update my site, all users' existing login cookies created with the 1.0 version of the site are no longer recognized by the 1.1.1 version of the site.
For reference, it took me quite a bit of work to get it set up, the solution in this stackoverflow post that I created is exactly how I have my site set up: http://stackoverflow.com/questions/37849816/swapping-azure-web-app-deployment-slots-logs-out-all-users-in-asp-net-core-rc2
Is there something I'm missing? Some extra step that I need to do now? A changed API? Any help would be appreciated!
Are you using slots to manage your upgrade? If so, unfortunately, this is a limitation of Azure Web Apps - they don't give use storage that can be shared between slots. You could move away from letting Azure Web Apps manage the keyring, and instead store it in blob storage, with PersistKeysToAzureBlobStorage. That would then be shared between slots.
public void ConfigureServices(IServiceCollection services)
{
services.AddDataProtection()
.PersistKeysToAzureBlobStorage(...);
}
This will end up creating a new keyring however, so everyone will get logged out, once.
Yeah, my old version of the site was using a custom IXmlRepository that stored it in blob storage. When I upgraded to .net core 1.1.1, I kept everything the same, told it to use the same keyring in that same blob. But even though it was using the same keyring, it couldn't read anything protected with the .net core 1.0 version of the site. I ended up having to just eat it and force everyone to log in again.
Where there any errors in the logs?
Which logs? I generally find it difficult to figure out what is logging and to where on Azure... so haven't played around with it much. I can check if you point me in the right direction though.
So I just updated to 1.1.2 version of all the .net core stuff, and same issue: cookies, antiforgery tokens or anything else that is encrypted, that was created with the 1.1.1 version of the site, is no longer readable by a version of the site running all the 1.1.2 libraries. This happens on localhost as well. Since I can debug this pretty easily on my local server now... what should I even look for? My dev site uses no fancy settings, just the basic .net core cookie authentication with no custom settings for data protection. Is the encryption somehow tied to the version number of .net core or something weird? Or did you just happen to change how it works in each of these releases?
@yellowsix just to be clear, are you using .NET Framework or .NET Core as your runtime?
I'm using .net core. It is an asp.net core web application. It is difficult for me to tell if the issue is with data protection directly, or with how asp.net core's cookie authentication and antiforgery modules choose to configure it... but twice now when upgrading from one version of the .net core libraries to another, it has made all protected data incompatible/unreadable. No other code changes were made in both cases, just nuget reference updates.
The reason I asked about runtime is that the bug you're describing looks like #187, "Cannot unprotect data after upgrading .NET Framework app to new DataProtection version". That bug is resolved in 2.0.0-preview1. We haven't seen this issue on .NET Core (i.e. <TargetFramework>netcoreapp1.1</TargetFramework>), only .NET Framework (i.e. <TargetFramework>net46</TargetFramework>).
Can you share a minimal repro that shows this issue on .NET Core?
Oh -- sorry I misread. Yeah we are targeting net46 as the runtime for the web application, so looks like this is the same issue, glad to see there is a fix in 2.0, and I'll keep track of whether you guys can squeeze in a backport of the fix to 1.x. Thanks!
Glad we cleared it up. We'll use #235 to track that.