Allow backwards-forwards navigation caching with antiforgery tokens

[fydar]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

Currently, using the default antiforgery implementation (DefaultAntiforgery) the headers "no-cache, no-store" are supplied.

The no-store header has the unfortunate side effect of slowing browser navigation by incurring additional web requests to the server whenever the user navigates using the forward and backward buttons.

From my (limited) understanding of antiforgery tokens, this should be entirely doable.

This results in a page diagnostics warning. The rest of the reasons for this error disappear without the debugger attached.

Disabling antiforgery site-wide is not simple nor does it appear to be officially supported.

Expected Behavior

Antiforgery should use no-cache instead of no-cache, no-store; or at least make this configurable so that backward-forward caching can be easily enabled.

Steps To Reproduce

1. Create a blank project

2. Disable dom preservation by replacing

   <script src="_framework/blazor.web.js"></script>
   

   With

   <script src="_framework/blazor.web.js" autostart="false"></script>
   <script>
       Blazor.start({
           ssr: { disableDomPreservation: true }
       });
   </script>
   

3. Add the time to the home page so we can see whether it's being cached

4. Launch the application.

5. Navigate from the home page to another page, and then navigate back to the home page using the back button.

6. Observe that the time has been updated, and in the network tab observe that a web request has been made.

You can check out the project here.
https://github.com/Fydar/AntiforgeryNoCacheIssue

Exceptions (if any)

No response

.NET Version

8.0.200

Anything else?

https://web.dev/articles/bfcache#minimize-no-store

[javiercn]

@Fydar thanks for contacting us.

I did a bunch of "archeology" and it seems that this was done 8 years ago here.

I'm not 100% sure what the reasoning at the time was. Although I suspect it might have had to do with bugs being present in browsers at the time.

I think it's reasonable for us to change this, but we'll have to do testing to ensure we don't introduce a regression on the behaviors this was aimed to address.

I think this might have had to do with proxies also not following the headers correctly.

Note for triage:

• If we decide to make this change, we should have E2E tests for this area covering all major browsers to ensure we don't regress anything.
• It's also likely that we want to rethink the value of the header, as we probably want to mark it as private to avoid storage in shared caches.