aspnetcore: Regression in AddDataProtection from RC2

I have a working app in ASP.NET Core 6 RC2. It stores data protection keys in Azure Blob Storage, and protects them with Key Vault:

builder.Services.AddDataProtection()
  .PersistKeysToAzureBlobStorage(new Uri(config["DataProtectionBlobUri"]))
  .ProtectKeysWithAzureKeyVault(
    new Uri(config["DataProtectionKey"]),
    new ClientSecretCredential(config["MicrosoftTenantId"], config["MicrosoftClientId"], config["MicrosoftClientSecret"])
  );

In the Dockerfile, if I change these lines:

FROM mcr.microsoft.com/dotnet/aspnet:6.0.0-rc.2 AS base
...
FROM mcr.microsoft.com/dotnet/sdk:6.0.100-rc.2 AS build

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
...
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build

Then the app still runs, but all existing cookies and encrypted strings are rejected. Reverting to RC2 makes everything work again.

An example error message is, when trying to decrypt a string: The payload was invalid. For more information go to http://aka.ms/dataprotectionwarning

The package versions are:

Azure.Extensions.AspNetCore.DataProtection.Blobs v1.2.1
Azure.Extensions.AspNetCore.DataProtection.Keys v1.1.0
Azure.Storage.Blobs v12.10.0

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 28 (19 by maintainers)

Most upvoted comments

I’d argue that the 6.0 change should be reverted to preserve back-compat with 5.0.

Tratcher on Nov 16, 2021

Ok, I’ve got it working! Thank you for all your help.

var builder = WebApplication.CreateBuilder(args);

// In .NET 6 RTM, manually set the Application Name to the RC2 default for backwards compatibility
var legacyContentRootPath = builder.Environment.ContentRootPath.TrimEnd('/');
builder.Services.AddDataProtection()
  .PersistKeysToAzureBlobStorage(new Uri(builder.Configuration["DataProtectionBlobUri"]))
  .SetApplicationName(legacyContentRootPath);

Moving forward, I wonder if it’s worth adding an analyser to help users avoid similar issues? For example: “You should include .SetApplicationName when adding data protection, to make sure it works consistently across deployment environments. For backwards compatibility, set it to the content root path.”

Or in .NET 7, perhaps mark the AddDataProtection() constructor as deprecated, and instead recommend AddDataProtection(applicationName)?

jamesgurung on Nov 17, 2021

The best part about making it a hotfix is that it’ll break 6.0 applications 😄

davidfowl on Nov 21, 2021

Trailing /s are normalization, they may or may not refer to a default document or a directory, because lol

blowdart on Nov 18, 2021