User invitation with caching server (Azure Front Door) does not work
Hello everyone,
I had a problem recently while inviting a user through the backoffice when there is a caching server (Azure Front Door with caching enabled in this case) in front of the Umbraco site.
When a user try to fill the password form sent by email and submit it, the POST request fails because of a missing cookie that contains the anti-forgery-token (UMB-XSRF-TOKEN and UMB-XSRF-V), so the user can never complete the form.
After digging in the Umbraco code, I found out that the request that set these cookies is /umbraco/backoffice/UmbracoApi/Authentication/GetCurrentInvitedUser but it seems that Azure Front Door is caching that request because the response has the header Cache-control: no-cache. When I disable caching, the form works fine.
I'm not sure if it's because the Cache-control header should have another part in it like no-store to make sure it never gets cached by Azure Front Door or the problem is from Azure Front Door itself.
The only way I was able to fix this problem without changing the Umbraco code is to add another routing rule with caching disabled and add the following matching pattern : /umbraco/backoffice/UmbracoApi/Authentication/GetCurrentInvitedUser. The only drawback of this fix is that it is pretty expensive to add a routing rule.
Azure Front Door (AFD) is documented to strip cookies if the response is cacheable:
If the origin response is cacheable, then the Set-Cookie header is removed before the response is sent to the client. If an origin response isn't cacheable, Front Door doesn't strip the header. For example, if the origin response includes a Cache-Control header with a max-age value indicates to Front Door that the response is cacheable, and the Set-Cookie header is stripped.
As indicated in the blog article above, no-cache does not mean don't cache, it just means revalidate before using the cache. It looks like AFD considers this "cacheable" and strips cookies.
Ironically another part of AFD documentation indicates that no-cache should be sufficient to indicate the response is not cacheable:
Some Cache-Control response header values indicate that the response isn't cacheable. These values include private, no-cache, and no-store. Front Door honors these header values and doesn't cache the responses, even if you override the caching behavior by using the Rules Engine.
However, this conflicts with yet another part of documentation where it states the X-Cache response debugging header only has value PRIVATE_NOSTORE when the request can't be cached:
PRIVATE_NOSTORE: Request can't be cached because the Cache-Control response header is set to either private or no-store.
So based on what you're also experiencing using no-store or private should fix the problem.
User invitation with caching server (Azure Front Door) does not work
Hello everyone,
I had a problem recently while inviting a user through the backoffice when there is a caching server (Azure Front Door with caching enabled in this case) in front of the Umbraco site.
When a user try to fill the password form sent by email and submit it, the POST request fails because of a missing cookie that contains the anti-forgery-token (
UMB-XSRF-TOKENandUMB-XSRF-V), so the user can never complete the form.After digging in the Umbraco code, I found out that the request that set these cookies is
/umbraco/backoffice/UmbracoApi/Authentication/GetCurrentInvitedUserbut it seems that Azure Front Door is caching that request because the response has the headerCache-control: no-cache. When I disable caching, the form works fine.I'm not sure if it's because the
Cache-controlheader should have another part in it likeno-storeto make sure it never gets cached by Azure Front Door or the problem is from Azure Front Door itself.The only way I was able to fix this problem without changing the Umbraco code is to add another routing rule with caching disabled and add the following matching pattern :
/umbraco/backoffice/UmbracoApi/Authentication/GetCurrentInvitedUser. The only drawback of this fix is that it is pretty expensive to add a routing rule.Anybody have an idea?
Original issue on GitHub where I detailed the problem: https://github.com/umbraco/Umbraco-CMS/issues/10270
TL;DR
Send either
no-storeorprivateinCache-controlheader.https://doodle.uk/blogs/2021/06/21/when-no-cache-means-cache-fun-with-azure-front-door
Long Version
Azure Front Door (AFD) is documented to strip cookies if the response is cacheable:
As indicated in the blog article above,
no-cachedoes not mean don't cache, it just means revalidate before using the cache. It looks like AFD considers this "cacheable" and strips cookies.Ironically another part of AFD documentation indicates that
no-cacheshould be sufficient to indicate the response is not cacheable:However, this conflicts with yet another part of documentation where it states the
X-Cacheresponse debugging header only has valuePRIVATE_NOSTOREwhen the request can't be cached:So based on what you're also experiencing using
no-storeorprivateshould fix the problem.is working on a reply...