I would like to understand the HTTP Client plugin better. Does it first send a request to rust backend? #13857
-
I'm trying to figure out why the http client plugin is necessary in my tauri application. If I don't use it I'm getting cors issues. To solve this I could relax the cors settings on the server (right?), but I've chosen the plugin solution instead. I have 2 questions: I've heard that the origin header is being set to the webview's origin. But what is the webview's origin? Is it the same as my web server? Does the plugin first send a request via ipc to the rust backend? If yes, what is the rust side doing exactly? btw this is my json capability file for the plugin; my server is running on {
"identifier": "fetch-http-capability",
"description": "Minimal set of fetch http capabilities",
"windows": ["main"],
"permissions": [
{
"identifier": "http:allow-fetch",
"allow": [{ "url": "http://localhost:3000/*" }]
},
"http:allow-fetch-send",
"http:allow-fetch-read-body"
]
}
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Correct You can get the current origin via I think it was window.location.href in js. You can overwrite this by setting an Origin header (an empty string removes the header). May require the unsafe-headers feature flag. Yes, the plugin, like all other plugins, have their actual logic on the Rust side. In this case this is how we are able to circumvent the cors restrictions in the first place. |
Beta Was this translation helpful? Give feedback.
Correct
You can get the current origin via I think it was window.location.href in js. You can overwrite this by setting an Origin header (an empty string removes the header). May require the unsafe-headers feature flag.
Yes, the plugin, like all other plugins, have their actual logic on the Rust side. In this case this is how we are able to circumvent the cors restrictions in the first place.
The rust side's logic is very simple, it just uses the reqwest crate to fire a normal http request 🤷