docs about insecure session cookies
Environment
Latest Safari and MacOS.
This library is being used by TanStack Start and I reported the issue there:
https://github.com/TanStack/router/issues/3492
This affects both the v1 and v2 branches.
Reproduction
The reproduction is given on TanStack Start example here: https://github.com/TanStack/router/issues/3492
But basically cookies will persist by default in Chrome and Firefox on MacOS but not Safari (and I suspect this also happens on iOS.)
Describe the bug
The culprit is in H3 on this line: https://github.com/unjs/h3/blob/67e12ae157876c8e5cd8e686ccb6efb1e467861c/src/utils/session.ts#L37
Basically DEFAULT_COOKIE is used as defaults in updateSession: https://github.com/unjs/h3/blob/67e12ae157876c8e5cd8e686ccb6efb1e467861c/src/utils/session.ts#L153 and also in https://github.com/unjs/h3/blob/67e12ae157876c8e5cd8e686ccb6efb1e467861c/src/utils/session.ts#L217
DEFAULT_COOKIE has secure = true.
But if you use http localhost on Safari in dev mode, cookies will not persist by default not, they will fail silently.
So if you do not specify a value for "cookie.secure" it will end up as true and thus Safari development mode will fail to save cookies.
Note be careful when setting 'secure' to true, as compliant clients will not send the cookie back to the server in the future if the browser does not have an HTTPS connection.
Maybe automatically change cookie secure setting based on process.env.NODE_ENV === 'production' or something similar? That is what I am suggesting to TanStack Start.
Additional context
Again, you can read my original issue over on TanStack Start here describing the issue: https://github.com/TanStack/router/issues/3492
Logs
This also effects users that are using chrome if you're doing dev testing over http (not https) on a local domain name like tailscale. We need the ability to set this flag dynamically. Verified if we manually change it in the /node_modules/h3/dist files that cookies are properly set again.
Overriding is fairly easy with session config { cookie: { secure: false } }, i think we can make the documentation more clear about this.