Closed nikoPLP closed 11 months ago
Can you try the dev
branch once #7677 has been merged in?
I can of course test that branch once the fix is merged, but after reading the bug report and the intended fix, I do not see this as related to my issue. I am having a security issue thrown by the browser because of mismatch origins. the browser doesnt allow ipc://
fetch in an https://
page. Even when adding CSP to the https page. As far as I understood the bug and fix you refer to, it is not the same issue.
Ok I understand you need a macos test of your fix, even though it is unrelated to my issue. Let me know once the merge is done on next
, and i ll introduce an options
argument in one of my commands to test it. That's fine!
And I understood everybody else is on vacation, so I ll wait for my own issue to be reviewed.
Seems like this only impacts macOS, WKWebView does some extended checks to prevent HTTPS to fetch a weird protocol :( We'll fallback to the postMessage IPC in this case.
nice to see a fix already @lucasfernog . I will test it in the coming days. 2 comments :
Not really, if you have a recent version of webkit2gtk installed (which is just a matter of time before it is available in all distros) and you enabled linux-ipc-protocol
feature flag, and you're not using remote URLs on macOS and iOS, then you have windows, macos, ios and linux support.
I will open another PR to extend this for iOS and also fix the channel response usage.
The new IPC is used on all platforms, even if it's just to send bigger responses to speed up the process. It's just a little bit slower on Linux and Android (plus remote URLs on Apple) but it's still a lot faster than v1 IPC.
Thanks for the clarification ! I will test all of that once the new PR will be coded and merged. Thanks!
Hello @lucasfernog, any news about the new PR ?
@nikoPLP the fix has been released, can you try with latest alpha?
Yes all is good for me with the latest release (tauri alpha.14, api alpha.8) I tested on all platforms, except iOS for which I don't have yet a dev env. Thank you very much!
Describe the bug
Nice to see an improvement on performances with the new IPC mechanism of #7170 .
It is obviously better to have data exchanged between the frontend and tauri, as body of POST requests instead of JSON in URLparam of a GET request.
But we shall note that this improvement is limited on platforms that are not android nor linux.
For me, it breaks a special use-case that I am having. I am loading a remote page (https) in a popup window from the tauri app, using the window API. In the popup window (not main) the javascript that is loaded contains the
@tauri-apps/api
and@tauri-apps/plugin-window
modules, and makes use of theWindow.getByLabel("main").emit()
API call to send a message to the main window.Until the breaking changes of
2.0.0-alpha.11
, this was working fine, except on android, because of the way messages are passed on that platform.Since the new IPC mechanism that uses
ipc://
fetch, I get a security exception on the client side of the popup window.No matter how much CSP header I injected on that page (via the HTTP server serving it), the error remains the same, as the page has an origin with
https://
andipc://
is considered insecure no matter what the CSP is saying.So my
https
page cannot send messages back to the main tauri window anymore.I guess this is a rare usecase, but I do make use of
ipc_scope().configure_remote_access()
API in the configuration of the tauri app, and I suppose that this API was meant specifically for this kind of use case, when a webpage making use of the client API is not served by tauri but by a remote server.So it seems that the new IPC mechanism is breaking any possible usage of
ipc_scope().configure_remote_access()
.I first decided to freeze the tauri version i am using to
2.0.0-alpha.10
and to cherrypick some bug fixes that appeared in the latest version, and that I needed.But then I thought this would not be future proof, so I decided to introduce a feature in tauri (in a fork of it, obviously) that would deactivate the new IPC mechanism and fall back to the old way using postMessage.
This crate feature that i named
no-ipc-custom-protocol
is quite minimalistic and seems to work on every platform i tested (all of them, except iOS that i don't have a dev env for, yet)Would you consider introducing this feature in the next alpha release ?
Also I would really like if @lucasfernog, the author of the refactor, could find another way to circumvent this limitation and allow
ipc://
to be fetched on anyhttps://
page, but I am not aware of any solution for that. Another way might be to dynamically fall back to the older IPC mechanism when the calling webpage is from a remote origin, and let the new mechanism work on webpages that are served by tauri. That would allow theipc_scope().configure_remote_access()
to make sense again in the new IPC mechanism context.The
no-ipc-custom-protocol
feature that I implemented can be found here : https://git.nextgraph.org/NextGraph/tauri/commit/ec9b62b3379f5353c6d8b9484e12ec82ef4fa34fLet me know if you want a merge request.
And thanks for your amazing work!
Reproduction
unfortunately I dont have enough time left for this issue to create a minimalist project that would reproduce this issue. Also, it would be a bit hard to setup as you need an external https server... But if you have some work on a branch that you want me to test, I will do it happily.
Expected behavior
See description of bug
Platform and versions
Stack trace
No response
Additional context
No response