Closed domodwyer closed 2 weeks ago
Hi,
thanks for your pull request. I'd like to first reproduce the error and check if your fix solves it. Could you please provide some steps to reproduce?
Hey!
So I tried to reproduce this in a "private browsing" window (clean session) but it didn't immediately reproduce! I guess this suggests it is caused by an extensions (perhaps adblock). For posterity here's what I saw:
But given it works in private browsing it's likely a local issue that I will try chase down.
However as I was typing this my session was invalidated and I was logged out! This is what had happened previously - I'm not really sure why though, it doesn't seem to be obviously a deterministic cause / effect thing.
That said I can't see why the client-side-set cookies should have the same attributes as the server side cookies, so hopefully this helps 🙏
I just installed the latest version (yay topomaps! thanks) but I can no longer log in.
When I try (including in a private window), I get 5 of the "non-HTTPS secure cookie" errors in the console:
It also doesn't work in Safari and Chrome, neither of which have been used to log into Wanderer before.
My fault. I was able to replicate the issue and published a fix in v0.7.1. If you can confirm the fix I will merge this request.
I checked this morning - it's perfect now! Enabling/disabling based on the protocol is much nicer too 👌
Thanks!
On Firefox 127.0 I reliably experience random logouts when opening new tabs, with a "secure cookie" error in the console - I serve wanderer over HTTP, so this is legitimate.
The server-side cookie response sets
secure: false
but the client side didn't - I'm assuming they should be in-sync / set the same attributes? I haven't got a dev environment set up so I can't confirm the fix but it seems likely (the firefox warning points to this client-side callback in the debugger).fix: disable "secure" mode on auth cookie (60edd92)
In Firefox a warning is displayed that states:
This warning is emitted from authStore.onChange callback.
The server-side cookie response contains the attribute "secure: false" which avoids this problem, but this was missing from the client side hook.