Strange CORS behavior.

[iohzrd]

I'm using ipfs-http-client in a simple test app to connect to the go-ipfs daemon. my CORS configuration for go-ipfs is such that it allows me to connect from my test app running in a browser but not tauri.

The dev console in tauri reports:

Origin tauri://localhost is not allowed by Access-Control-Allow-Origin.

I've tried adding "tauri://localhost", "tauri://" and even to my CORS config but it doesn't help.

A thing of note is that my tauri.conf.json is set to serve directly from the public directory for dev and dist. When I load the page from a dev server on localhost in various browsers, everything works as expected. When I load file://index.html in various browsers, i get

Origin null is not allowed by Access-Control-Allow-Origin.

but then if I add "null" to the CORS configuration, everything works as expected. I've tried adding various values to my CORS config, but nothing I've tried allows the connection in tauri.

Another thing of note is: I compiled go-ipfs with some added logging and it appears the CORS values don't reflect what tauri is reporting.

here are the logs from connecting with a browser:

DEBUG   cmds/http   http/handler.go:90  incoming API request: /id
WARN    cmds/http   http/handler.go:130 Origin: http://localhost:5000
WARN    cmds/http   http/handler.go:132 User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.164 Safari/537.36
WARN    cmds/http   http/handler.go:134 referer: 

and here are the logs when trying to connect from tauri:

DEBUG   cmds/http   http/handler.go:90  incoming API request: /id
WARN    cmds/http   http/handler.go:128 API blocked request to /id. (possible CSRF)
WARN    cmds/http   http/handler.go:130 Origin: 
WARN    cmds/http   http/handler.go:132 User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
WARN    cmds/http   http/handler.go:134 referer: 

Note that; The origin reported in tauri is "tauri://localhost" but in the go-ipfs log it's blank.

The expected behavior is that, with the correct CORS configuration, ipfs-http-client should successfully connect to go-ipfs.

$ npm run tauri info
Operating System - Manjaro, version 21.1.0 X64

Node.js environment
  Node.js - 16.5.0
  @tauri-apps/cli - 1.0.0-beta.6
  @tauri-apps/api - 1.0.0-beta.5

Global packages
  npm - 7.20.2
  yarn - Not installed

Rust environment
  rustc - 1.53.0
  cargo - 1.53.0

App directory structure
/src
/node_modules
/src-tauri
/scripts
/public

App
  tauri.rs - 1.0.0-beta.5
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../public
  devPath - ../public
  framework - Svelte
  bundler - Rollup

A final note is that; I've tried setting CSP to "", but it doesn't help.

[pzeinlinger]

I can confirm this bug.

[ghost]

I believe what is happening here is tauri includes an origin: tauri://localhost request header for cross origin requests.

Many servers (especially ones out of your control) may not expect this origin, and so the request is blocked and you will see that error.

[pzeinlinger]

Unfortunately, that's not true. Using curl and manually setting origin to tauri://localhost works. What I found is that the webview expects the Access-Control-Allow-Origin header to be tauri://localhost but does send an empty string.

[nothingismagick]

Thanks for filing the issue. From our Discord discussion about this right now by @Beanow:

Do you happen to have a snippet of the fetch and curl request you're making? It's often worthwhile validating what the actual request is a server sees with something like > https://hub.docker.com/r/traefik/whoami

[Beanow]

I was indeed able to reproduce the issue @pzeinlinger is describing.

What I found is that the webview expects the Access-Control-Allow-Origin header to be tauri://localhost but does send an empty string.

Here's a simple server to test different origins with. https://gist.github.com/Beanow/ccb667d1d7ffc674dedd7e54a62800ec

It seems to be a type of bug related to the custom protocol tauri:// and not setting the Origin: header correctly. Using "devPath": "http://localhost:5000", so we're not running from the custom protocol and CORS works as expected.

[Beanow]

@iohzrd I see you mentioned

I've tried adding "tauri://localhost", "tauri://" and even to my CORS config but it doesn't help.

For me it did work to use * though. (Of course this isn't desirable and tauri://localhost should work ideally). Can you try the minimal reproduction I added in the gist? https://gist.github.com/Beanow/ccb667d1d7ffc674dedd7e54a62800ec

[pzeinlinger]

• is not an option if credentials are involved. https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

Am 11.08.2021 um 20:48 schrieb Robin van Boven @.***>:

 @iohzrd I see you mentioned

I've tried adding "tauri://localhost", "tauri://" and even to my CORS config but it doesn't help.

For me it did work to use * though. (Of course this isn't desirable and tauri://localhost should work ideally). Can you try the minimal reproduction I added in the gist? https://gist.github.com/Beanow/ccb667d1d7ffc674dedd7e54a62800ec

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Beanow]

Fully agreed @pzeinlinger. I'm asking only to get a full picture of the bug. If your setup responds differently to * than my setup, the problem might have another dimension to it. Please don't run any productions servers with *.

[iohzrd]

Interestingly enough, I just ran my original test on my windows machine, and it doesn't have the same issue. Accepting wildcard in ipfs CORS config enables http-ipfs-client to successfully connect to IPFS. So, it's appears to be a linux specific issue.

[iohzrd]

I'm also not running into this issue on linux using wry directly.

[wusyong]

@iohzrd Did you test from custom_protocol or rpc example on wry? Because others are in https origin afaik

[iohzrd]

i used the custom_protocol example

[iohzrd]

I must be confusing something. I just re-ran my wry test and it's having the same issue as well. Not sure what was different last time or if I'm just misremembering.

[lucasfernog]

We also face CORS issues when requesting a custom protocol (for instance fetching the asset protocol from the tauri protocol in tauri - fetch('asset:///path/to/something')).

[iohzrd]

@Beanow

To be clear, I only experience this issue when loading my page via

  distDir - ../public
  devPath - ../public

and not when loading from a local dev server.

[Verequies]

I am also experiencing this CORS issue. Even allowing 'tauri://localhost' doesn't work, and on my backend Tauri doesn't even present 'tauri://localhost' as the Origin meaning I can't dynamically allow the client. This has pretty much broken my software as I am unable to make any requests to my backend.

[Mehdish1]

Mehdish

[wusyong]

I opened an upstream issue on Webkit's bugzilla. In the meantime, if you want to make a HTTP request, you could use our HTTP fetch function.

[Verequies]

@wusyong Thanks for the suggestion. I was able to make it work with Tauri HTTP fetch with a few caveats. Is there a way that the Tauri HTTP fetch method can read cookies - other than specifying them yourself? I wrote about there not being a way to access cookies in another issue as well #2490.

[mlouielu]

Add an PoC test for this: https://github.com/mlouielu/tauri-origin-test-app

Even if I use custom warp to remove CORS check in check_request, server still gave CORS denied.

[wusyong]

I got a notification from webkitgtk team that 2.34.0 just released yesterday and it fixed this issue. It's not landed on each distro yet, but I can confirm it works! Result below is from @mlouielu 's repo without any change.

[mlouielu]

Can confirm that webkit2gtk 2.34.0 works!

Build webkit2gtk with:

cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja -DCMAKE_INSTALL_PREFIX=/usr -DLIB_INSTALL_DIR=/usr/lib -DWEBKITGTK_API_VERSION="4.0"

[gardc]

Perhaps the new webkit2gtk version will fix issue #1836 too?

[iohzrd]

Can confirm that webkit2gtk 2.34 fixes the issue with "tauri://localhost" in my cors config. Expected behavior.