SAFE Browser Fetch API best practice


What would be the disadvantage of disabling CORS with either no-cors or webSecurity: false? I’m somewhat familiar with CORS and the reasons behind its creation and I don’t know if they are relevant to SAFE.

Personally I’d prefer it if SAFE Browser was entirely Rust-based as appears[0][1] to be possible. For now, I’d be satisfied if I could fetch via XOR-URL and continue on with the SAFE app I’m developing.

1 Like


Using your fork and branch I’ve attempted to disable the CORS error with { mode: 'no-cors' } in both instances of fetch and webSecurity: false in the three instances of webPreferences. Alas, the CORS error remains.

Whether advisable or not, how can I modify the code to have the request allowed? I would like to continue developing my app, with a custom SAFE Browser build if necessary, while the exact official method is separately worked on.

Yeh a pure rust browser would be great. But practically speaking, that’s not going to happen for some time though.

@anon78698497 I think you should be able to add Access Control headers to the js code i linked to above to allow * , which should turn off CORS.

Another alternative would be to use the safe api itself to do your fetch for you, which won’t hit CORS. (I’m not sure that means we should turn CORS off though…).

here’s an explanation of electron’s webSecurity option:

I think this sort of thing is still reasonable to have even on SAFE.


Would you please show an example or snippet? I tried that with no success however I may have made a mistake.

If you recall two weeks ago I was trying that.

I’ve read that page. I’m aware of the potential security risks however being that I’m only accessing/testing code I write, and I’m now nearly three weeks of wasted time, if I don’t get this basic functionality in place soon I’ll have to stop developing for SAFE until considerable progress is made and I would very much prefer to avoid that.

@anon78698497 i’m sorry if you feel there’s wasted time here, some of this is as you’re blazing a trail here. which is massively useful in terms of shining a light on what’s missing.

What I recall is you trying to use the browser native fetch, for wasm. Which had issues in terms of the HTTP response being lacking. What I was trying to suggest above (although not that clearly I now see) was to use the javascript safe api to instantiate an app and then call safe.fetch(<url>). That would get your data without any CORS issues.

Though that in itself is more JS app level than using yew, which I know is what you’re aiming for here. It may be you could use the rust safe-api for this in your code directly. Though I’m not sure at all if this will compile for wasm. It may be worth a try though.

I’ve made this branch and you can see the commit here to enable this. I think should get us around the CORS issue.

In general @anon78698497 if you feel the APIs aren’t intuitive or are missing something as you’re developing. We’re super open to feedback. You can feel free to raise an RFC much as @shane has done for missing apis over here so we can improve / add anything missing. HTTP responses, naming etc are all valid topics to be getting in to :+1:



I’ve built the SAFE Browser branch and the error remains.


FilesContainer created at: "safe://hnyynywy171fpi6xxptsbkz7cda5y7w3k7jtpp71h7oacy8ydbkwfgbgkhbnc"
+  file.css    safe://hbhyyyn5ox7wd6qyhri8cybrsj7azz4uxmuyhq4e1saxim7fsrjhsqc4fg
+  file.js     safe://hbkygydhuquhis85sbu9ek6jhidc7ynbumuxn8nf7s36fau4ob6ge1ho6q
+  file.wasm   safe://hbyyyyd5gf4kgeacnapdarhb7kq8nhitwwax3woc9an9xoatrtqt11tn9y
+  file.json   safe://hbkygonp7f5b84pdzu7yrqti9gr8hgtjtysyjswa55zpz7jbrfeku9g8hh
+  index.html  safe://hbhybyn7rws4pupisrocmx4rnb5k5oh7oawmmwaaton9b96zzrmta85mtc

I load the app, enter the file.json XOR-URL (safe://hbkygonp7f5b84pdzu7yrqti9gr8hgtjtysyjswa55zpz7jbrfeku9g8hh) and it fails to fetch with

Access to fetch at ‘safe://hbkygonp7f5b84pdzu7yrqti9gr8hgtjtysyjswa55zpz7jbrfeku9g8hh/’ from origin ‘safe://hnyynywy171fpi6xxptsbkz7cda5y7w3k7jtpp71h7oacy8ydbkwfgbgkhbnc’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

Ach, seems I’d missed a trick in the server there and we weren’t forwarding all headers :man_facepalming:

I’ve updated the branch now.

You can see that the access control header is set in the devtools network panel.

and then you can also see:

1 Like


That solved it, thank you.

1 Like

great stuff


Is that ready for testing?

Would you also please add support for audio/flac? It may be beneficial to identify a [semi-]official source of known types and automate the regular importation of it. is an example of such a list, is another, and there are others.

Here is the list of what’s supported @anon78698497,, we can always add more types to it, perhaps we can have a poll in the community to see what other types we all see as needed, then we add them altogether, and we can repeat this process in a while again when more uses cases are being covered by apps and more types required/missing…?


Nope sorry. Been on other things the last week. But with @bochaco’s link you should be able to make a PR with desired changes there :+1: That would be much appreciated.


Unfortunately I don’t use GitHub and Improving SAFE's contribution accessibility didn’t go anywhere so I cannot. I found a workaround so adding the media type isn’t urgent.

I wasn’t aware of that, let’s give it a wee bump


While the alpha build at Lack of local development priority has restored a functional local development environment, the CORS error solved by your branch has returned. Would it be possible to have the fixes of your branch added to the main repo?

1 Like

Absolutely. This completely slipped my mind. Will get into that now :+1:

A beta build has been fired up with this fix in:

1 Like


Thank you. I’ve tried 0.18.0-beta.0 and the error remains.

Oh really? :thinking: hmmm.

Looks like it missed the server side use of the updated headers in my cherry-pick there :frowning:

Updated beta.1 on the build :+1:

1 Like


I’ve tried 0.18.0-beta.1 and the error remains.

As far as I can see, We’ve got all the relevant changes from that branch in the current one. So not sure what’s missing.

Can you provide a minimal example with steps for reproduction against a local testnet please. :bowing_man:

1 Like