Origin wails://wails is not allowed by Access-Control-Allow-Origin

[davidhaley]

Description

Hello,

I am attempting to make a network request to an external resource from the front-end, and I am receiving this error:

Origin wails://wails is not allowed by Access-Control-Allow-Origin
Fetch API cannot load <url> due to access control checks.

Is there a recommended place to set the access control header?

Thank you!

To Reproduce

To reproduce, send a fetch request to an external resource (e.g. YouTube).

Expected behaviour

It is expected that the network request is not blocked.

Screenshots

No response

Attempted Fixes

No response

System Details

System
------
OS:     EndeavourOS
Version:    Unknown
ID:     endeavouros
Go Version: go1.18.3
Platform:   linux
Architecture:   amd64

Wails
------
Version:        v2.0.0-beta.38
Package Manager:    pacman

Dependency  Package Name    Status      Version
----------  ------------    ------      -------
*docker     docker      Installed   1:20.10.17-1
gcc     gcc     Installed   12.1.0-2
libgtk-3    gtk3        Installed   1:3.24.34-1
libwebkit   webkit2gtk  Installed   2.36.4-2
npm     npm     Installed   8.14.0-1
pkg-config  pkgconf     Installed   1.8.0-1

* - Optional Dependency

Diagnosis
---------
Your system is ready for Wails development!

### Additional context

_No response_

[misitebao]

Due to the restriction of the same-origin policy, the function you mentioned cannot be implemented temporarily. It is recommended to use go to send the request, and then return the result to the front-end part.

Please refer to the answer here: https://github.com/MicrosoftEdge/WebView2Feedback/issues/2558

[davidhaley]

Thank you.

[sarim]

Umm maybe this issue should be kept opened? @davidhaley It's not "solved".

For future googlers and future me:

Windows: https://github.com/wailsapp/wails/blob/ec56f8807f4df98e43fe9c2cac156e91f858915c/v2/internal/frontend/desktop/windows/frontend.go#L36

Linux: https://github.com/wailsapp/wails/blob/ec56f8807f4df98e43fe9c2cac156e91f858915c/v2/internal/frontend/desktop/linux/frontend.go#L35

Mac: https://github.com/wailsapp/wails/blob/ec56f8807f4df98e43fe9c2cac156e91f858915c/v2/internal/frontend/desktop/darwin/frontend.go#L37

So cors error would happen (and it happens) in linux and mac, as it uses a special "wails://" protocol. The issue doesn't happen in windows as it uses http://.

Not sure why the behavior is inconsistent here, also why hardcoded const instead of a config in json? Also a flag in json that enables --disable-web-security would be really helpful here.

[stffabi]

So cors error would happen (and it happens) in linux and mac, as it uses a special "wails://" protocol. The issue doesn't happen in windows as it uses http://.

Not sure why the behavior is inconsistent here, also why hardcoded const instead of a config in json? Also a flag in json that enables --disable-web-security would be really helpful here.

Unfortunately there are technical reason why we have to use wails:// on macOS and Linux, there one can't use a custom scheme handler for a scheme that WebKit already supports by itself. Therefore it's impossible to use http:// or https://. On Windows the early versions of WebView2 didn't have the possibility to register a custom scheme, so http://wails.localhost was the workaround there. Since newer WebView2 versions support registering schemes, we probably will switch to use wails://wails an Windows too. Then Wails would use the same scheme on all platforms.

--disable-web-security would help on Windows (with all it's security drawbacks, see also #1507). On Linux that could probably be used as well or disabling CORS just for the wails:// scheme. But AFAIK there's no possibility to do this on macOS, at least not without using private APIs which would have their own drawbacks.

Hope this helps to clarifiy the situation a little bit.

[sarim]

@stffabi Thanks for clarifying the situation. For me the issue was the app I'm developing needs firebase authentication. This needs to be done in javascript / frontend. Firebase javascript client sdk has many magics to automatically refresh tokens and other stuff.

So this

It is recommended to use go to send the request, and then return the result to the front-end part.

It's impossible for my above-mentioned use case. As I'm not doing the fetch/xmlhttpquest, but firebase's sdk library is going that.

For reference this is the error I get in linux:

Cross-origin redirection to http://developers.google.com/ denied by Cross-Origin Resource Sharing policy: Origin wails://wails is not allowed by Access-Control-Allow-Origin. Status code: 301

Fortunately, while I'm developing this app in ubuntu, Actual users for this app will use windows (It's a company internal app for staff).

This is really a deal-breaking issue and needs to be highlighted more in website/README IMO. Otherwise, people might write their app using wails dev mode and only encounter this after building for production. (Like stupid me)

--disable-web-security should be the default IMO. But I'll be happy with a flag in wails.json. This whole CORS thing is JUST a web browser thing. Wails here is a desktop app development framework. If you write desktop app in c / c++ / java / python / qt / wxWidgets / dart / flutter any other decent language in the world, nobody gonna nuke your HTTP request for this WEB only CORS protocol.

I apologize for ranting; I was up against a deadline and debugging this cost me half a day :(

[stffabi]

This is really a deal-breaking issue and needs to be highlighted more in website/README IMO.

Yeah that would be a good idea.

--disable-web-security should be the default IMO. This whole CORS thing is JUST a web browser thing. Wails here is a desktop app development framework. If you write desktop app in c / c++ / java / python / qt / wxWidgets / dart / flutter any other decent language in the world, nobody gonna nuke your HTTP request for this WEB only CORS protocol.

Wails is a desktop app development framework but it's also a browser engine and as such there are security implications depending on what one is going to do. There are no limitations when doing HTTP requests from the Go side.

From my personal perspective I wouldn't like to see this as default value. I would prefer to see secure defaults which can be lifted if someone really wants that. There's no real documentation what all is going to be disabled with that flag, it might be CORS only it might also be full file:// access from any source. So if someone is going to load an external javascript (probably one shouldn't do that), that script might get full file system access. Microsoft said they are not going to provide an API for this due to Security-Concerns. Electron also states in their docs "do not disable WebSecurity in production".

I apologize for ranting; I was up against a deadline and debugging this cost me half a day :(

No worries, every discussion about such things are good to get the project forward. I'm sorry to hear you have lost so much time with this issue.

[leaanthony]

This is one of the reasons Dev mode also presents the application not just a browser. I'm personally not a fan of using the browser to develop because we cannot guarantee that everything works. I think disabling it by default would be a step in the right direction.

[sarim]

This is one of the reasons Dev mode also presents the application not just a browser. I'm personally not a fan of using the browser to develop because we cannot guarantee that everything works

The application started by wails in dev mode also uses http. I'm not using browser, I am using the application to develop. location.href in javascript returns "http://localhost:34115/". To be consistent with production, wails then should also use wails:// here.

[stffabi]

This is one of the reasons Dev mode also presents the application not just a browser. I'm personally not a fan of using the browser to develop because we cannot guarantee that everything works

The application started by wails in dev mode also uses http. I'm not using browser, I am using the application to develop.

location.href in javascript returns "http://localhost:34115/". To be consistent with production, wails then should also use wails:// here.

Unfortunately that would mean loosing the frontend dev experience with vite, since that's needed to support vite reloads (websockets). There are some tradeoffs due to technical restrictions and features one wants to support.

[sarim]

Hmm, it looks like there is no real benefit of using wails:// protocol. Maybe just running a real http webserver at a random port a solution? Just like wails dev. Obviously then there will be a concern of other apps on computer accessing it via localhost. Do the browser engines support modifying requests (MITM)? Then maybe a special header with a key could be inserted and golang server would only accept requests verifying that header.

[c1ngular]

@leaanthony Any solution ? I am having same problem on wails CLI 2.5.1 on macos m1 . All requests fails due to access origin control

[leaanthony]

@c1ngular - Please open a new ticket for this and detail what you have tried to fix it. Thanks.