tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
85.1k stars 2.57k forks source link

[MacOS / Linux] WebKit doesn’t set Secure cookies on localhost #2604

Open Tragio opened 3 years ago

Tragio commented 3 years ago

Describe the bug

Thank you for the amazing work, progress and transparency with the community.

I’m going through a challenge with WebKit. I’ll try to be a brief as possible.

My app is based on Nuxt, using Nuxt Auth with HTTPOnly and Secure Cookie, Axios, and connects to the backend through Axios proxy and withcredentials.

I found out that my app was not login in on Safari/Tauri. After taking a look when it comes to setting Secure cookies locally, not all browsers behave in the same way. For example, Safari doesn’t set Secure cookies on localhost, but Firefox and Chrome do.

To test, I generated a local SSL Certificate and it works on Safari and Tauri Dev but not on Tauri Build.

Set-Cookie: XSRF-TOKEN=eyJ0eXAiOiJK; expires=Fri, 08 Oct 2021 18:47:22 GMT; HttpOnly; Max-Age=2592000; Path=/; SameSite=Lax; Secure

References

https://web.dev/when-to-use-local-https/

Update

The same behavior is happening in the Linux environment.

wravery commented 3 years ago

If I'm reading that right, the Linux version could be fixed here with https://localhost: https://github.com/tauri-apps/wry/blob/3a6eefae66c41da0f09293911675cb3c094e58b5/src/webview/webkitgtk/mod.rs#L212

And the macOS version would be here: https://github.com/tauri-apps/wry/blob/3a6eefae66c41da0f09293911675cb3c094e58b5/src/webview/wkwebview/mod.rs#L404

amrbashir commented 3 years ago

/upstream tauri-apps/wry

tauri-apps[bot] commented 3 years ago

I have created an upstream issue at https://github.com/tauri-apps/wry/issues/444, I will notify you once it is resolved.

wusyong commented 3 years ago

I've post it on #2490 but I'll post it here again in hoping for more feedbacks. I've been searching possible ways to do it on Linux and macOS, but it seems a dead end. Custom URL scheme on wkwebview just can't handle cookies properly.

There are some workarounds but I'm not sure if they are easier than setting IFrame. We can provide a method to set the cookie before loading pages/requests. And the implementations could be:

What do you guys think which is better?

wusyong commented 3 years ago

Or we could just load the page @wravery suggested. But that mean we will need another way to load assets (CSS, js, ...) Because they are also using custom protocol to load.

arnaudambro commented 2 years ago

hi @wravery @amrbashir

I'm not specialist of cookie so I don't understand the whole discussion

but I'm finding out that my app on macOS can't use cookie, it doesn't work :( in dev and in production, same result

is it something you say it can't be fixed ? or is it something that you plan to fix on your roadmap ?

thanks for the great job anyway, I just setup my whole webapp in tauri in a couple of hours, and it's working like a charm (except the cookie part)

👏👏

arnaudambro commented 2 years ago

oh, I didn't see [MacOS / Linux] WebKit doesn’t set Secure cookies on localhost

donkey-donkey commented 2 years ago

Hiya. Is there any fix in sight for this problem? Or should we pursue other techniques for OSX deployment? Thank you.

JonasKruckenberg commented 2 years ago

Hiya. Is there any fix in sight for this problem? Or should we pursue other techniques for OSX deployment? Thank you.

As you can tell from the upstream issue, this is actively being worked on. If you want to see results faster than that, feel free to contribute!

ulgut commented 2 years ago

Hi @JonasKruckenberg – is there an active issue on the Webkit repo for this? Or is this issue specific to the Tauri project?

FabianLars commented 2 years ago

@jessetuglu These ones probably https://bugs.webkit.org/show_bug.cgi?id=232088 https://bugs.webkit.org/show_bug.cgi?id=218980 No movement at all unfortunately. Not that it would really matter since webkit updates won't be shipped to older macos releases, but still...