How to handle CORS and Same Origin Policy issues?

[Kukulkano]

Hi. I plan to write some client software and found WebUI as a great option. But the web application I want to run uses WASM and is making calls to some websites to get data (API REST calls).

In the past, it always failed because of missing sufficient CORS headers on server side and issues with the Same Origin Policy. I understand that the API holder does not want to send a CORS header with *. If I want to run a web app in WebUI (or any other web gadget) I always run against these issues. I would need a way to force the used webbrowser to ignore CORS and Same Origin Policy. But I found no such option. Is there a practical way to get around these limitations? How do you guys handle these issues?

[AlbertShown]

The first thing to clarify is that WebUI is only a tool to connect your application to the web browser to use it as your main GUI. All other things, like CORS, are entirely out of control by WebUI.

Normally, the server-side control handles the request or ignores it. So, the client should respect the server-side rules and put the necessary headers. Keep in mind that your application is running on 127.0.0.1. So your client can easily modify the header before sending it using xhr.setRequestHeader('custom-header', 'value');.

[Kukulkano]

Hi Albert. May I ask you about your experience with WebUI and end users? I mean, do you ask people to install a specific web browser? Or do you rely on WebUI to find a suitable one? If it does not find one, do you ask people to install a specific one? Do you have experience in reliability of such solution? Do many people have to install additional web browser? I mean, thousands of our end users are not IT experts. More like the average WhatsApp user. They would not be able or allowed to install other software...

[AlbertShown]

• We rely on webui to figure out the web browser. In most cases, it's Chrome. Otherwise, it's the currently running web browser
• Our product (Software) comes as a setup package, so all needed files are already included
• We decided to go with the DLL version, so our installer can easily update the webui dll if needed.
• No issues are reported, except one user (our support guy) said he close Yandex first to force webui to pick up Chrome (So, maybe it's a good idea if we add webui_disable_specific_browser(Yandex);)
• In general, the end-user does even notice he is using a web browser... they even congrats us because they like the new UI design
• Our software controls a big machine through LAN, so all that webui does is send clicks events and update the motors speed value through JavaScript in the UI... that's all, so that's why it's working perfectly for us for now
• The last thing... consider using something other than the current repo version. It's a mess right now!, clone 2.0.3 and patch it as needed instead

[Kukulkano]

Thanks Albert. Sounds interesting. Our app will have much more functionality. It has to integrate with the OS (to handle specific files) and it has to do web API calls and to run a WASM component (encryption and compression stuff). The GUI itself is the minor part.

So you don't ship a web browser, right? You just rely on WebUI finding a usable and up to date browser. I wonder what happens if we do so for >10.000 end users... Is someone having expericence with WebUI in that field (many thousand end users)? If that would trigger a support call for every 20th user, it would be a nightmare.

For the repo version, this was a good hint. I also had a look and found that WebUI is not maintaining an official stable or LTS branch (for example for only fixing bugs but not implementing any new features). We've had very bad experiences with such components in the past. Every new version we were forced to pull for fixing a bug also introduced new bugs because of new functions and API changes. By this, we were forced to do a full QA cycle for every time we did a pull on that component for just getting rid of an annoying bug. That was very bad and cost us many many hours and also some hair... This is definitely a disadvantage of WebUI :-(

[AlbertShown]

WebUI is not maintaining an official stable or LTS branch

In our case, we have our own private webui 2.0.3 LTS. I submitted to this current branch most patches we did locally.

Is someone having expericence with WebUI

Our project is used right now by our customers only (companies), so around 300 - 500 technicians around the globe. Our UI is simple, that's why our QA validate it in the first test.

I wonder what happens if we do so for >10.000 end users

In our case, the UI does not have any open/read files, but when I tested the text-editor example, I noticed that sometimes the OpenFile dialog in Windows loses the focus (Shows behind the UI window), not a big deal but QA may report a bad UX. But this issue never happens in Linux or macOS.

So you don't ship a web browser, right?

If we need to ship a web browser, then we will switch to React and re-write the whole project in JavaScript. The main reason for using webui is to make our software package very small, multi-platform, modern UI... and the most unique and fantastic feature of webui is we can use our favourite programming language in the backend.

has to do web API calls and to run a WASM component

I have no WASM experience, but someone reported that WASM won't run correctly in any local host. So, you may need to patch webui to change the domain or something... I'm not sure.

[Kukulkano]

Thanks Albert.

someone reported that WASM won't run correctly in any local host

IMHO, the main issue is, that WebWorkers do not work at all if the files are loaded from localhost :-( But that is not a WebUI issue.

sometimes the OpenFile dialog in Windows loses the focus (Shows behind the UI window)

This is weird but maybe not a real issue. Maybe even a problem with only a specific browser? But thanks for pointing to it.

In our case, we have our own private webui 2.0.3 LTS. I submitted to this current branch most patches we did locally.

So, basically, you say you run your own stable local branch and cherry pick any bug fixes from the master branch into it? I understand. But from my experience, cherry picking patches can have bad side effects if you're not deep in the project code by itself. As I do not plan to dig deeper into WebUI itself, this is possibly a dangerous plan for my project. I will have to think about this.

[delphius]

Hi Delphius. Thanks, but how does the linked xpath module help me with my question? Did I miss an important point?

Hi, this is not just an xpath module, it is part of a general program using webui, which parses data from external sources to form a representation. As already mentioned, webui by itself is not able to solve the CORS problem in any way, and the presented module is a solution to your problem using a special publicly available free CORS proxy. You asked how webui users solve this problem, I showed you a specific way that works for me, without any complications.

For your purposes, only one specific line is enough, the link to which I gave, so that firstly there was a clear example of practical use, and secondly, on the site itself, which provides this specialized proxy service, you can get the details of use. But, I repeat, this has nothing to do with the webui library used at all, it is rather a practical issue that falls into its ecosystem when applied in practice.

Or maybe I completely misunderstood the question, sorry.

[Kukulkano]

Ah, thanks! I did not understand your intention, sorry. I will have a look!

[delphius]

No problem. Fell free to contact me for any question if any