#Changing protocol/request origin on Windows

13 messages · Page 1 of 1 (latest)

oblique pond
#

Hi there 👋

I'm working on an app which makes requests to ollama, an app which will be running on the same machine as my app.

While ollama's default cors policy does make an allowance for requests coming from tauri://* it does not make the same allowance for requests coming from https://tauri.localhost

My app works just fine on macos, since it seems to default to sending requests using the tauri protocol. However, I get blocked by cors on Windows.

I can technically set an environment variable for ollama to add the windows origin, but this would require users to restart ollama the first time they use my app, which is annoying.

Is there any way to configure Tauri such that the Windows build of my app sends requests from the tauri:// protocol? Or even from localhost without causing significant security issues?

I understand that the tauri:// protocol is not used on Windows in order to support windows 7 and 8, but I do not personally care about that in this case as I am comfortable not supporting those versions for my app.

Thanks!

noble vine
#

I understand that the tauri:// protocol is not used on Windows in order to support windows 7 and 8, but I do not personally care about that in this case as I am comfortable not supporting those versions for my app.
those protocols use completely different webview apis so you can't switch them out no matter if you care about win7.
This should still work though: https://github.com/tauri-apps/tauri/discussions/4912 (windows only)

oblique pond
#

Gotcha, this looks like it will work fine for Windows. Thanks!

oblique pond
#

@noble vine sorry for the ping but I'm really having a hell of a time with this lol

I'm not the world's best Rust programmer, but I would like to learn so if you have the time to explain what is going on and how I might go about fixing it I'd appreciate it!

I'm currently calling two functions:

pub unsafe fn AddWebResourceRequestedFilter<P0>(&self, uri: P0, resourcecontext: COREWEBVIEW2_WEB_RESOURCE_CONTEXT) -> windows_core::Result<()>
where
    P0: windows_core::Param<windows_core::PCWSTR>,```

```webview2_com_sys::Microsoft::Web::WebView2::Win32::ICoreWebView2HttpRequestHeaders
pub unsafe fn SetHeader<P0, P1>(&self, name: P0, value: P1) -> windows_core::Result<()>
where
    P0: windows_core::Param<windows_core::PCWSTR>,```

My calls look like this:

```core.AddWebResourceRequestedFilter(
    &HSTRING::from("*"),
    COREWEBVIEW2_WEB_RESOURCE_CONTEXT_ALL,
)
.unwrap();```

```.SetHeader(
    &HSTRING::from("Origin"),
    &HSTRING::from("localhost"),
)```

I feel like I must be doing something foolish here because the first call, the one to `AddWebResourceRequestedFilter` is giving me an error while the second call to `SetHeader` is not, even though the type signatures appear identical to me.

I doubt I can fit the full compiler warning in here, but a key part of it may be:

```type mismatch resolving `<&HSTRING as TypeKind>::TypeKind == CopyType`
required for `&HSTRING` to implement `windows_core::param::Param<windows_strings::pcwstr::PCWSTR, windows_core::r#type::CopyType>`
...
perhaps two different versions of crate `windows_core` are being used?
...
can_into.rs(5, 1): trait impl with same name found
can_into.rs(1, 1): there are multiple different versions of crate `windows_core` in the dependency graph```

Looking at `cargo tree -p windows-core` I can see that I do indeed have multiple versions of `windows-core` installed. Specifically, `0.52.0`, `0.57.0`, and `0.60.1`.

Is there something I should be doing to reconcile these versions, or is there some way I can specify which version I would like to use here? Or am I just off-base and off my rocker?

Thanks for the help, let me know if I can further clarify anything.
noble vine
#

yeah matching versions is important. For Tauri 2.5 you need [email protected] [email protected] in your Cargo.toml. I don't think you need to worry about windows-core if those versions match.

#

the windows bindings changed a bit in recent versions so the examples in that discussion may all not be 100% correct (similar to how the one i posted didn't work anymore when MirazMac posted theirs).

#

If that version stuff doesn't help i'd appreciate it if you could share the whole with_webview block so i can see the whole picture

oblique pond
#

Alright, those changes do indeed make the code run. Now I'm hitting an issue where it seems to me like the Origin is being replaced with localhost, but there is perhaps something else I need to be setting to get this thing working.

The console is showing this error:

Access to fetch at 'http://localhost:11434/' from origin 'https://tauri.localhost' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'http://localhost' that is not equal to the supplied origin. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

And the network tab shows these two requests repeating themselves, the first with type fetch in red showing no status and the second with type prefetch coming back with a 204.

The first has a warning that it is showing "Provisional headers" - I'm not entirely sure what that is or why it is doing that.

  -H ^"sec-ch-ua-platform: ^\^"Windows^\^"^" ^
  -H ^"Referer;^" ^
  -H ^"User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 Edg/135.0.0.0^" ^
  -H ^"sec-ch-ua: ^\^"Microsoft Edge WebView2^\^";v=^\^"135^\^", ^\^"Chromium^\^";v=^\^"135^\^", ^\^"Not-A.Brand^\^";v=^\^"8^\^", ^\^"Microsoft Edge^\^";v=^\^"135^\^"^" ^
  -H ^"Content-Type: application/json^" ^
  -H ^"sec-ch-ua-mobile: ?0^"```

```curl ^"http://localhost:11434/^" ^
  -X ^"OPTIONS^" ^
  -H ^"Accept: */*^" ^
  -H ^"Accept-Language: en-US,en;q=0.9^" ^
  -H ^"Access-Control-Request-Headers: content-type^" ^
  -H ^"Access-Control-Request-Method: GET^" ^
  -H ^"Cache-Control: no-cache^" ^
  -H ^"Connection: keep-alive^" ^
  -H ^"Origin: http://localhost^" ^
  -H ^"Pragma: no-cache^" ^
  -H ^"Referer: http://localhost/^" ^
  -H ^"Sec-Fetch-Dest: empty^" ^
  -H ^"Sec-Fetch-Mode: cors^" ^
  -H ^"Sec-Fetch-Site: cross-site^" ^
  -H ^"User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 Edg/135.0.0.0^"```
noble vine
#

While ollama's default cors policy does make an allowance for requests coming from tauri://* it does not make the same allowance for requests coming from https://tauri.localhost
I interpreted this as a bug but they actually include tauri://* in the defaults. Why not ask them to add http://tauri.localhost as well?

#

It looks like chrome's preflight request doesn't trigger webresourcerequested (or any webview2 events) so overwriting the origin for this usecase seems to be impossible

#

that would leave us with the --disable-web-security flag but that's a bit much just for this if you ask me

oblique pond