Issues with antiforgery token being decrypted after Azure slot swap
Hi,
I am using slot swapping and using the recommended settings (v11.2.0), and everything is working very well except for the
AntiforgeryValidationException.
Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The
antiforgery token could not be decrypted. --->
System.Security.Cryptography.CryptographicException: The key
{NOTSHOWINGACTUALKEYIN_FORUM} was not found in the key ring. For
more information go to http://aka.ms/dataprotectionwarning at
Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.UnprotectCore(Byte[]
protectedData, Boolean allowOperationsOnRevokedKeys, UnprotectStatus&
status) at
Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.Unprotect(Byte[]
protectedData) at
Microsoft.AspNetCore.Antiforgery.DefaultAntiforgeryTokenSerializer.Deserialize(String
serializedToken) --- End of inner exception stack trace --- at
Microsoft.AspNetCore.Antiforgery.DefaultAntiforgeryTokenSerializer.Deserialize(String
serializedToken) at
Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery.GetCookieTokenDoesNotThrow(HttpContext
httpContext)
What I've found for possible solutions is to use a data store for the tokens, such as Azure Blob Storage or Redis, which you would do like so:
Assuming someone doesn't have an existing solution that comes out of the box with Umbraco, where is the right place to call this? I see that in the IUmbracoBuilder call to AddWebsite(), it calls AddDataProtection(), and there's no way to inject yourself in there (and there's even a TODO regarding load balanced setups).
So would calling it before or after this call work?
I have exactly the same problem on version 12.3.3. I also use slot swapping, but I think the problem started to appear after I changed the App Service Plan. How did you fix it?
We've started to notice this issue lately as well, I'm not sure if it has been there for a while and we've only noticed it lately or if this is something new.
For us it's present in the latest v13 (13.2.2) and I've managed to replicate it on the latest v12 (12.3.9) and in some cases v11 (11.2.1).
My investigation indicates that there's a problem with how the backoffice creates/validates it's anti forgery tokens. In our case it works well when running the site via Kestrel (dotnet run) and IIS Express, however, the issue shows up in these scenarios:
We reycle the App Pool on any v12 or v13 site (not v11)
We run the IIS app pool using a custom identity (not ApplicationPoolIdentity), a recycle would trigger the error. This indicates that the fact that we have another identity for app pool means that this identity does not have permission to read/write the keys.
We switch between app pools (even when running as default ApplicationPoolIdentity). The only thing we do is switch between two app pools with the same settings.
I've tested anti-forgery tokens on the front end and they "survive" in all the scenarios above where the backoffice token does not.
The fact that I've consistently managed to replicate the issue when switching app pools in IIS might indicate that the issue is similar to what is happening when you do slot swap in Azure?
I need to investigate a little more but it seems like there is something strange around how the backoffice anti-forgery tokens are stored, maybe they ignore the setting from AddDataProtection() which causes the key ring for the anti-forgery token to be stored in memory or some strange place that is dependent on the current app pool.
I'll create an github issue around this and share my findings.
Issues with antiforgery token being decrypted after Azure slot swap
Hi,
I am using slot swapping and using the recommended settings (v11.2.0), and everything is working very well except for the AntiforgeryValidationException.
What I've found for possible solutions is to use a data store for the tokens, such as Azure Blob Storage or Redis, which you would do like so:
Assuming someone doesn't have an existing solution that comes out of the box with Umbraco, where is the right place to call this? I see that in the IUmbracoBuilder call to AddWebsite(), it calls AddDataProtection(), and there's no way to inject yourself in there (and there's even a TODO regarding load balanced setups).
So would calling it before or after this call work?
Thanks in advance!
I have exactly the same problem on version 12.3.3. I also use slot swapping, but I think the problem started to appear after I changed the App Service Plan. How did you fix it?
Well I wouldn't say I "fixed" it, but I think I mitigated it somewhat. I still see errors in the logs on a swap, but I think it's less than before.
Call AddDataProtection then PersistKeysToAzureBlobStorage
var blobSection = configuration.GetSection("Umbraco:Storage:AzureBlob:Media");
AzureBlobFileSystemOptions blobOptions = new();
blobSection.Bind(blobOptions);
services .AddDataProtection() .PersistKeysToAzureBlobStorage(blobOptions.ConnectionString, "SomeContainerName", "Someblob.xml");
Hey - has someone else had this problem still? We are seeing this on slot swap in v13, so might need to look to implement something like this
Has anyone seen similar?
Hi!
We've started to notice this issue lately as well, I'm not sure if it has been there for a while and we've only noticed it lately or if this is something new.
For us it's present in the latest v13 (13.2.2) and I've managed to replicate it on the latest v12 (12.3.9) and in some cases v11 (11.2.1).
My investigation indicates that there's a problem with how the backoffice creates/validates it's anti forgery tokens. In our case it works well when running the site via Kestrel (dotnet run) and IIS Express, however, the issue shows up in these scenarios:
We do have the key ring stored on disk like this:
I've tested anti-forgery tokens on the front end and they "survive" in all the scenarios above where the backoffice token does not.
The fact that I've consistently managed to replicate the issue when switching app pools in IIS might indicate that the issue is similar to what is happening when you do slot swap in Azure?
I need to investigate a little more but it seems like there is something strange around how the backoffice anti-forgery tokens are stored, maybe they ignore the setting from
AddDataProtection()
which causes the key ring for the anti-forgery token to be stored in memory or some strange place that is dependent on the current app pool.I'll create an github issue around this and share my findings.
EDIT: Issue is not created here: https://github.com/umbraco/Umbraco-CMS/issues/16107
Update:
I have found a work around that solves the problem for us:
https://github.com/umbraco/Umbraco-CMS/issues/16107#issuecomment-2066368483
is working on a reply...