I've tried setting the cookie as non-http-only, and I got the same issue: cookies are available during the session (although still not visible in the devtools cookie inspector), but not persisted.

• Using EventSource (SSE events) do not include the cookie, as none is found in the cookie storage within the dev tools

if using the http plugin, cookies and requests will not show in the devtools inspector at all as the requests are made through Rust.

• Restarting the app forces a re-auth, as the cookie (with the JWT token) is not part of the storage.

I see, this is because the cookies jar is created each time the app is started and not persisted on disk. This part we can improve.

Is it possible to use XHR directly, without relying on the http plugin?

The problem with the plugin is those cookies are required for other things than fetch, like EventSource (SSE).

On a browser, the cookie storage is shared, so if you get a cookie set via an HTTP request, that cookie will be sent back with EventSource messages, but that's not the case with the plugin.

And, given that the plugin does not expose any kind of cookie, there is no workaround possible (aside of not relying on cookies for authentication / JWT).

you can use XHR or the built-in fetch directly, and it will store and load cookies as needed

The tauri http client is not 100% replacement and it will never be (although it tries to be very close). You should only use the tauri http client when there is a good reason for it, like bypassing CORS.

I think I'm missing something (maybe you can point me in the right direction?): using XHR for requests works, but I'm not getting any cookie in the response, while the same request on a browser, returns a cookie.

Is there anything specific I need to set in order to be able to get cookies back from a remote API? The request itself hits the remote server and gets a response back, it's just the cookies that should be there that I'm missing.

which browser did you try with? could you see if epiphany browser (gnome-browser) have the same bug?

I've done a bunch of testing, and this is the scenario:

• Firefox, chrome based browser: works fine on any OS.
• Epiphany: works as well, I can see the cookies on the network tab, but I couldn't find the cookie on the devtools storage, as it's only showing the cookies for the current domain. Opening a new tab and entering the domain of the API, revealed the missing cookie, so everything fine.
• Tauri on linux: doesn't work, the cookie does not appear on the network tab for the request that is setting it
• Tauri on mac: doesn't work, but this time the cookie does appear on the request that is setting it, but following request (that should include that cookie), don't show it as part of the request.

In both Tauri cases, I could not change the domain to the API's to check if the cookie was actually available in the storage.

you could try directly with one of the examples in wry repo and use webview.cookies() API to check stored cookies

That could be an option, but kind of defeats my idea of using tauri: I was expecting to just package the SPA app within tauri, fix the base paths that would need fixes and be done, but not having basic cookie management (with similar behavior to what the web does), becomes a blocker.

Maybe is that my expectations are not correct, but IMHO being able to perform authenticated REST calls to external services is a must.

I'll try to perform the fix on tauri myself, although I'm not proficient on Rust yet (WIP). If I manage to get it done, I'll raise a PR.

I am suggesting to use wry and webview.cookies() just to confirm whether the cookies you're looking for are stored or not, this hopefully gives us a bit of information so we can try to fix it properly.

I just tried and I can see the cookies just fine in the network tab, feel free to make a minimal repro and I will be happy to check it