13

We have a react front-end that is communicating with an ASP Core API.

Sometimes we detect there is something wrong with the front-end, including service workers, local cache, and that kind of stuff, so we want to tell the client to clean it up.

I've implemented the Clear-Site-Data (dev-moz) (w3c) as a response header, as "Clear-Site-Data": "cache", "cookies", "storage", "executionContexts"

When testing this out in Firefox, it works, and in the console I'm seeing:

Clear-Site-Data header found. Unknown value “"executionContexts"”. SignIn
Clear-Site-Data header forced the clean up of “cache” data. SignIn
Clear-Site-Data header forced the clean up of “cookies” data. SignIn
Clear-Site-Data header forced the clean up of “storage” data.

When doing the same in Chrome, it's not working, and I'm seeing the message

The request's credentials mode prohibits modifying cookies and other local data.

I'm trying to figure out what to do to fix it, but there are barely any any references. Just 7 results, mostly from browser integration test logs

All the documentation says that this should be implemented and working in Chrome... Any idea what's the problem?

Ron Sijm
  • 8,490
  • 2
  • 31
  • 48
  • have you managed to find a solution to this? No matter what I do, I tried the solution idea given below by Greg, it doesn't clear the cache. – oividiosCaeremos Oct 11 '21 at 11:07

2 Answers2

2

Try manually reloading the page after the Clear-Site-Data has been received (so that the local data / cache is cleared and the header no longer contain Clear-Site-Data).

Both Firefox & Chrome don't appear to support executionContexts, which tells the browser to reload the original response.

If header contains executionContexts, then the browser should ignore it (as you see in Firefox console). However you can try wildcard mapping (*). (This will also add support for future properties).

Response.AppendHeader("Clear-Site-Data", "\"*\"");

Also Google reuse parts of their Chrome source code in their open source project Chromium. If you take a look at Chromium source code (https://doss-gitlab.eidos.ic.i.u-tokyo.ac.jp/sneeze/chromium/blob/9b22da4739ec7bf54fb8e730662e2ab7996532e0/content/browser/browsing_data/clear_site_data_handler.cc line 308). This implements the same exception The request's credentials mode prohibits modifying cookies. A flag LOAD_DO_NOT_SAVE_COOKIES is somehow being sent. The console error maybe an caused by an additional response header or a small chance theres a bug in Chrome.

Greg
  • 4,468
  • 3
  • 16
  • 26
  • It seems that Chrome returns `Unrecognized type: "*".` when you pass the wildcard. For reference, this is in Chrome 96. – Dan Atkinson Nov 26 '21 at 09:33
  • It was supported from 61. However it's marked as 'Experimental. Expect behavior to change in the future.' See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data – Greg Nov 28 '21 at 11:45
2

Right now, my advice would be do not implement the Clear-Site-Data header at this time.

Despite the spec being widely available for some years, vendor support is still hit-and-miss and is now actually going in reverse.

As per the w3c github for this, there are a number of issues regarding executionContexts. The wildcard ('*') mentioned by Greg in their answer is not supported by Chrome, and Mozilla are about to remove the cache value as well.

All this points to a flawed standard which is likely to be removed at some point in the future.

Dan Atkinson
  • 11,391
  • 14
  • 81
  • 114