Adding actix-cors to a simple actix-web + leptos template causes compiler target issues?

help
1

Commands I did, exactly in this order

cargo leptos new --git leptos-rs/start
//change to new dir
cargo add actix-cors
cargo leptos watch

error: This wasm target is unsupported by mio. If using Tokio, disable the net feature.
  --> C:\Users\me\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\mio-1.1.1\src\lib.rs:44:1
   |
44 | compile_error!("This wasm target is unsupported by mio. If using Tokio, disable the net feature."); 
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  

error[E0432]: unresolved import `crate::sys::IoSourceState`
  --> C:\Users\me\.cargo\registry\src\index.crates.io-197f\mio-1.1.1\src\io_source.rs:14:5
   |
14 | use crate::sys::IoSourceState;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^ no `IoSourceState` in `sys`

error[E0432]: unresolved import `crate::sys::tcp`
  --> C:\Users\me\.cargo\registry\src\index.crates.io-19497f\mio-1.1.1\src\net\tcp\listener.rs:20:5
   |
20 |     tcp::{bind, listen, new_for_addr},
   |     ^^^ could not find `tcp` in `sys`

error[E0432]: unresolved import `crate::sys::tcp`
  --> C:\Users\me\.cargo\registry\src\index.crates.io-1949f\mio-1.1.1\src\net\tcp\stream.rs:17:17
   |
17 | use crate::sys::tcp::{connect, new_for_addr};
   |                 ^^^ could not find `tcp` in `sys`

I've done a bit of research and it seems that since I'm trying to use CORS middleware on a wasm32-unknown-unknown target, I might be trying to do the impossible as per

which states
"Browsers do not allow WASM to make network requests. You need to write that part in Javascript and pass the results to WASM via FFI."

So, correct me if I'm wrong, but for my goal of letting the client bypass CORS without having to host the CORS middleware on the server end, I'll either:
A: Bundle a JS CORS middleware to the client so they can run it locally, or
B: Do the same t hing but bundle a Rust actix-cors to the client along with a JS FFI.

What do you all think?

2

I'm not sure I understand your setup. Your server has to respond with the CORS headers. You can't manipulate them in the browser, be that via WASM or JS. The browser fetches a cross-site request and checks the CORS headers, and only if the current site is allowed to access the site the request was made to, will the response be made available to your code by the browser.

3

You would need to explain wht you are trying to do in some more detils because so far the description sounds more-or-less like “if I want to steal piled of gold from Fort Knox and it looks like my options are Ⓐ, Ⓑ, and Ⓒ”.

Well… this may even be true, but the question then is, of course, how badly do you want to steal that gold and how much do you plan to spend on fighting guards.

CORS exist for a reason, and browsers fight tools that circumvent these for a reason, which means you may end up with something that would be detected and removed by vrious anti-virus tools… this may or may not be a problem for you depending of what do you actually try to do, but it's not the question of “which technical solutions may I need” but more of “why do you believe what you try to is even a good thing”.

This probably wouldn't work, because there are no local component that may bypass CORS.

Then you would be forced to pass everything through that component, which means, in turn, that security software would declare your app “a trojan” with some fancy name and it would be removed by many security tools. This may or may not be a problem for you, though. E.g. if it's strictly for the intranet, then chances that it'll work is high… but the next question, then, is “why do you need browser at all”. Standalone client sounds easier, at this point.