User story around on cookies + authentication

[Nickersoft]

Hey folks,

I've been toying with the idea of porting my SvelteKit app to a Tauri app for some time now (while still keeping a version on the web), and am confused about the user story regarding cookies + network authentication in Tauri. I couldn't find any solid docs on it, and am curious how other people are managing their apps.

Right now user authentication in my app is very straightforward:

1. User logs in
2. Server authenticates and sets a Secure cookie specific to my app's domain
3. All subsequent requests pass this cookie, and the server authenticates for each incoming request
4. If authentication fails, the app attempts to get a new cookie set via a refresh endpoint / refresh token
5. If refreshing the token fails, it logs the user out

However, in the world of Tauri, this approach seems to break down. Tauri apps run off tauri://localhost, which is neither a Secure origin (from my understanding), or a valid domain name. AFAIK my cookies will never be set. There's also the issue of CORS, which I tried to disable by setting csp to null, but it didn't seem to work when I tried, plus it just feels wrong.

I tried using the Tauri http module to circumvent it, but it's not compatible with SvelteKit's fetch signature (though I know this will be fixed by #5136). I tried using the store plugin, but its reliance on window makes it impossible to run server-side, which breaks SvelteKit's dev server.

Regardless, trying to balance both cookie-based and store-based authentication resulted in a ton of messy boilerplate as I tried detecting the environment the app was being run.

Anyway, I was surprised to see there is not a user story around this detailed in the Tauri docs. I'm curious how other people are managing similar setups.

[Nickersoft]

...does no one else have this problem? 😭

[FabianLars]

does no one else have this problem?

Others do too: #2604

but its reliance on window makes it impossible to run server-side, which breaks SvelteKit's dev server.

How so? If it doesn't work with the dev server it shouldn't work after build either, you need to wrap it in a app env check or onMount. But the store plugin is not reallyyy suitable for sensible data anyway since it's a plain json file on disk, but then again the webview's cookies are not saved much better either 🤷 (especially on linux where it's just a text file lol)

Anyway, I was surprised to see there is not a user story around this detailed in the Tauri docs

i guess because external urls/resources were basically out of scope for v1 (for example tauri's apis are disabled on external websites). And well we don't have any user stories in the docs, at least if we think about the same kind of user stories.

[Nickersoft]

Hey @FabianLars! Thanks so much for responding. I had seen #2604 but wasn't sure if it was directly related or not, so I just thought I'd voice a separate discussion. I've been subscribed to that issue for awhile haha.

As for the store plugin, IIRC I think it's because it imports appWindow, which causes it to immediately fail in server environments. This effectively means you have to dynamically load the module inside an onMount(). I can double-check on this though. Pretty sure it was the issue.

In general, I guess I'll just have to wait if it's out-of-scope 😅 I love what you folks are doing and have been watching the project closely. Hopefully, this kind of use case is supported soon!

[FabianLars]

As for the store plugin, IIRC I think it's because it imports appWindow, which causes it to immediately fail in server environments. This effectively means you have to dynamically load the module inside an onMount(). I can double-check on this though. Pretty sure it was the issue.

Yep, sounds about right.

Hopefully, this kind of use case is supported soon!

Sooner or later it will! It's just a tricky subject in the context of security/auditing, there is a lot to do and even more to mess up

[alexwohlbruck]

I'm trying to figure this one out, 2 years later. What did you settle on? HTTP plugin?

[daveycodez]

Solved. Override window.fetch

Here's a React example but it can be adapted.

import { isTauri } from "@tauri-apps/api/core"
import { fetch as tauriFetch } from "@tauri-apps/plugin-http"

  useEffect(() => {
      if (isTauri()) {
          const originalFetch = window.fetch

          window.fetch = async (...args) => {
              const [input] = args
              const href = (input as URL).href

              if (href?.startsWith("http")) {
                  return tauriFetch(...args)
              }

              return originalFetch(...args)
          }

          return () => {
              window.fetch = originalFetch
          }
      }
  }, [])
    ```

[Nickersoft]

How are you handling auth @daveycodez?

[daveycodez]

Better Auth. I made a package https://github.com/daveyplate/better-auth-tauri

[Nickersoft]

Looks slick! Though after digging through the code I'm still curious how the session is actually being managed. I looked at Better Auth's docs (haven't used it before) and it seems to rely on setting session cookies, but I thought these kind of cookies won't work in Tauri? Tyler Nickerson

…

On Jun 1, 2025, 1:25 PM -0400, daveycodez ***@***.***>, wrote: Better Auth. I made a package https://github.com/daveyplate/better-auth-tauri — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[daveycodez]

It does indeed use cookies. The package automatically routes requests through the Tauri HTTP Plugin which fixes cookies for native Mac apps.