Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Philippe G 1 post 71 karma points c-trib
    May 17, 2021 @ 20:06
    Philippe G
    0

    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.


    Anybody have an idea?


    Original issue on GitHub where I detailed the problem: https://github.com/umbraco/Umbraco-CMS/issues/10270

  • Rahul Patel 8 posts 80 karma points
    Aug 24, 2023 @ 18:10
    Rahul Patel
    1

    TL;DR

    Send either no-store or private in Cache-control header.
    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:

    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.

Please Sign in or register to post replies

Write your reply to:

Draft