Delete cookies before syncing them from WebView to HTTPCookieStorage

[ibrahima]

This PR deletes cookies before syncing them from the WebView session to HTTPCookieStorage. Otherwise, when cookies are deleted on the WebView side of things, they may never get deleted from HTTPCookieStorage, which can lead to unexpected behavior.

I ran into an issue with our app where we were using URLSession.shared to make a request to log in to the app, and then copying cookies from HTTPCookieStorage to the WebView. On log out, we delete cookies relevant to the previously logged in user, and this does delete them from the WebView. But when we log back in to a different user account, the cookies from the previous user get restored. I looked around and it seems like deleted cookies in the WebView never get deleted from HTTPCookieStorage, though I don't know for sure if my understanding is correct. But I was able to solve it in my app by deleting all cookies on logout. But I think it makes most sense to fix it here, upstream, so that this issue doesn't bite other people. It seems like the logically correct thing to do to ensure that cookies are always in sync with what the WebView session has.

[joemasilotti]

I think this should be handled in your application code, not the library.

If a developer manually sets some cookies in HTTPCookieStorage (outside of the ones from the web view) then this PR will delete them on every page load.

[ibrahima]

Hmm maybe, but if a developer manually sets cookies that overlap with ones from the webview they would already get overridden. It seems a little surprising that it syncs cookie creation from the backend but not deletion. At least for me it felt like a footgun that setting cookies in Rails gets propagated to the http cookie storage but deleting cookies in Rails does not.

Perhaps the safest thing would be to only delete cookies that were deleted on the server side based on the headers, but that would be a bit more complicated (not sure if we could do it here).

Hmm, I have felt for some time that Hotwire Native needs an equivalent to @rails/request.js. I think that if we had something like that, it could have its own specific cookie store and URLSession rather than using URLSession.shared, and then keeping them in sync 100% would make sense and wouldn't affect the shared cookie store. It would also be handy to have something that automatically extracts CSRF tokens for you so that you can just make HTTP requests to your Rails backend from native code. Unfortunately I feel like I'm only masquerading as an iOS developer so I don't know what the best way to write such a library would be or if this even makes sense, but I think it would be a significant unlock for Hotwire Native.

I also wanted to mention, I don't know if this behavior is documented anywhere? I forget where I figured out these cookies were even being copied but it wasn't clear to me; I had thought that there was no way for me to make authenticated requests to my backend but was pleasantly surprised that I could actually do that (at least for GET requests) out of the box.

[joemasilotti]

It seems a little surprising that it syncs cookie creation from the backend but not deletion.

Then your server should send the cookie with an expired expiration date and the existing code will delete it.

[ibrahima]

That is what rails is doing, is it not? The cookies get deleted from the webview but not the http cookie storage because it's only looping over cookies that exist in the webview at the time that we sync, and those deleted cookies no longer exist.