The new cookies API doesn't actually set cookies in Safari?

[kevinrenskers]

Describe the bug

I've migrated to SvelteKit 1.0.0-next.475 and its new cookies API, and logging into my website no longer works, cookies are no longer set at all.

Reproduction

https://github.com/kevinrenskers/sk-cookie-bug

On the homepage I show the token which is stored in a cookie, which of course defaults to undefined. There is a link to a login page, which has a login button. This does a request to a local endpoint, which sets a cookie. It then redirects you back to the homepage, and that token should now be updated.

In reality the token is still undefined, and looking at the cookies in the storage inspector, there is nothing there.

This used to work with the previous set-header method just fine.

Logs

No response

System Info

System:
    OS: macOS 12.5.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 574.67 MB / 32.00 GB
    Shell: 3.5.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 16.17.0 - ~/Library/pnpm/node
    npm: 8.15.0 - ~/Library/pnpm/npm
  Browsers:
    Safari: 15.6.1
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.71
    @sveltejs/kit: next => 1.0.0-next.475
    svelte: ^3.44.0 => 3.50.0
    vite: ^3.1.0 => 3.1.0

Severity

blocking an upgrade

Additional Information

No response

[kevinrenskers]

Update: it works fine in Microsoft Edge and in Chrome, but not in Safari (version 15.6.1).

[teemingc]

I think it's because secure: true is the default when using cookies.set.

Safari doesn't allow setting https only cookies on http connections, while other browsers understand we are developing and it doesn't matter.

Try adding secure: false in the cookie options and it should work in Safari.

[kevinrenskers]

You're right, setting secure specifically to false fixes the problem. Ugh.
Maybe SvelteKit should use the dev environment value to automatically do this, instead of always using secure: true as the new default.

[kevinrenskers]

Deleting cookies doesn't seem to work either, in none of the browsers. I've added a logout button to my example repo which deletes the cookies in a server endpoint but nothing happens, cookie is still there. Not just in Safari, also Chrome.

[teemingc]

Deleting cookies doesn't seem to work either, in none of the browsers. I've added a logout button to my example repo which deletes the cookies in a server endpoint but nothing happens, cookie is still there. Not just in Safari, also Chrome.

I have a related issue #6609 (waiting for it to be re-opened as it still persists).
You can try the workaround mentioned here. This involves using cookies.set to set an expired cookie.

[kevinrenskers]

Ha yea I just found the same workaround. But even then the homepage doesn't update to reflect the newly deleted token, even when calling invalidateAll().

[cdcarson]

Maybe SvelteKit should use the dev environment value to automatically do this, instead of always using secure: true as the new default.

@kevinrenskers I see your point, but that might open another can of worms. "Hey, what happened, SvelteKit's making my secure cookies insecure!"

AFAICT Safari is the main problem -- Chrome and FF accept secure cookies over http://localhost. Not sure about Edge, but it should be Chrome-like. Maybe the solution is documenting this?

[kevinrenskers]

Why is SvelteKit choosing the default to be secure anyway, if that causes problems in a major browser? Seems better to leave it up to devs to set this themselves, then there is no hidden behavior that you then have to work against.

[CaptainCodeman]

I think it would be clearer if the defaults matched the regular cookie-setting defaults, especially if not doing so breaks things on a major browser.

With normal cookies, they are secure if you set them to be.

Next best would be using the dev flag, which is what anyone who wants secure cookies will end up using anyway.

[benmccann]

This is hopefully fixed in the latest release by #6811