I am trying to speed up my site by caching my pages with the Workbox service worker. It works great unless I am using it on a page that allows users to login. I have a login control in the comments section of all my posts which users use to login and post
comments, but if the page is being cached using the Workbox StaleWhileRevalidate method
https://developers.google.com/web/tools/workbox/modules/workbox-strategies the page refreshes to the pre-authenticated cached version and if the user tries to login again they get a runtime error saying "Validation of Anti-XSRF token failed."
I attribute this problem due to how Workbox updates its cache using StaleWhileRevalidate. It fetches a page from cache while also updating the cache from the network. This works good for pages that are frequently updated like articles with comments because
one only needs to load the page a couple times to see what just changed. Unfortunately this process is a step behind and leads to problems. I was able to come up with a temporary workaround using NetworkFirst, but that defeats the purpose of caching unless
the application goes offline. This temporary workaround still results in the same runtime error if a user tried to logout from a cached page. They are logged out, but the page still displays their information as if they were still logged in. Then if they click
the logout link again they get the error.
I am wondering if I might be able to clear specific Workbox caches by name when the user is logged in. I was thinking maybe using an onclick event handler for the linkbutton in the login control. One that if the form is valid would delete the cache.
I am not sure how one would access the logged in status of a user from a service worker, but I have found examples of people accessing the worker from the DOM. My understanding is that service workers lack DOM access.
.NET forums are moving to a new home on Microsoft Q&A, we encourage you to go to Microsoft Q&A for .NET for posting new questions and get involved today.
I noticed the problem on pages that were using StaleWhileRevalidate also, so I had to change it to NetworkFirst on any page that uses a button for anything. I have several pages with search controls that were getting the error when clicking the search button.
Seems like the token fails if the the page being served is from the cache. I am guessing that means they don't match.
I never added this XSRF feature to the site. It just came that way because I used the default web forms template in Visual Studio. Do I really need this feature or is it the kind of thing I could limit to just certain pages?
I never added this XSRF feature to the site. It just came that way because I used the default web forms template in Visual Studio. Do I really need this feature or is it the kind of thing I could limit to just certain pages?
As far as I think,this has to happen to add XSRF feature to your site.
Best regards,
Yijing Sun
.NET forums are moving to a new home on Microsoft Q&A, we encourage you to go to Microsoft Q&A for .NET for posting new questions and get involved today.
Member
4 Points
204 Posts
Anti-XSRF Token Failure Due to Service Worker Caching
Dec 31, 2020 10:14 AM|CopBlaster|LINK
I am trying to speed up my site by caching my pages with the Workbox service worker. It works great unless I am using it on a page that allows users to login. I have a login control in the comments section of all my posts which users use to login and post comments, but if the page is being cached using the Workbox StaleWhileRevalidate method https://developers.google.com/web/tools/workbox/modules/workbox-strategies the page refreshes to the pre-authenticated cached version and if the user tries to login again they get a runtime error saying "Validation of Anti-XSRF token failed."
I attribute this problem due to how Workbox updates its cache using StaleWhileRevalidate. It fetches a page from cache while also updating the cache from the network. This works good for pages that are frequently updated like articles with comments because one only needs to load the page a couple times to see what just changed. Unfortunately this process is a step behind and leads to problems. I was able to come up with a temporary workaround using NetworkFirst, but that defeats the purpose of caching unless the application goes offline. This temporary workaround still results in the same runtime error if a user tried to logout from a cached page. They are logged out, but the page still displays their information as if they were still logged in. Then if they click the logout link again they get the error.
I am wondering if I might be able to clear specific Workbox caches by name when the user is logged in. I was thinking maybe using an onclick event handler for the linkbutton in the login control. One that if the form is valid would delete the cache.
My Workbox cache method is as follows:
workbox.routing.registerRoute( new RegExp('(.*)/posts/(.*)'), workbox.strategies.networkFirst({ cacheName: 'posts', plugins: [ new workbox.expiration.Plugin({ maxEntries: 60, maxAgeSeconds: 30 * 24 * 60 * 60, purgeOnQuotaError: true, }), new workbox.cacheableResponse.Plugin({ statuses: [0, 200] }), ], }), );I am not sure how one would access the logged in status of a user from a service worker, but I have found examples of people accessing the worker from the DOM. My understanding is that service workers lack DOM access.
Contributor
3360 Points
1279 Posts
Re: Anti-XSRF Token Failure Due to Service Worker Caching
Jan 01, 2021 06:04 AM|yij sun|LINK
Hi CopBlaster,
Accroding to your description,as far as I think,you need to remember to Opt-in to CORS Mode.And then you could get back opaque responses.
You could use NetworkFirst and StaleWhileRevalidate.Also, you could use Opaque Responses.
More details,you could refer to below article:
https://developers.google.com/web/tools/workbox/guides/handle-third-party-requests
Best regards,
Yijing Sun
Member
4 Points
204 Posts
Re: Anti-XSRF Token Failure Due to Service Worker Caching
Jan 02, 2021 08:14 AM|CopBlaster|LINK
I noticed the problem on pages that were using StaleWhileRevalidate also, so I had to change it to NetworkFirst on any page that uses a button for anything. I have several pages with search controls that were getting the error when clicking the search button. Seems like the token fails if the the page being served is from the cache. I am guessing that means they don't match.
I never added this XSRF feature to the site. It just came that way because I used the default web forms template in Visual Studio. Do I really need this feature or is it the kind of thing I could limit to just certain pages?
Contributor
3360 Points
1279 Posts
Re: Anti-XSRF Token Failure Due to Service Worker Caching
Jan 05, 2021 07:56 AM|yij sun|LINK
Hi CopBlaster,
As far as I think,this has to happen to add XSRF feature to your site.
Best regards,
Yijing Sun