SAFE Browser Fetch API best practice


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


Pardon me, I was mistaken. I’ve tested and the CORS error is resolved. Despite the CORS error, the actual cause was that I had forgotten to upload the fetched files to the new vault instance. Therefore, what should have been a 404 Not Found error was being reported in the console as a CORS error. (example)

Being that CORS bypass is possibly temporary, I’ll leave it to you to decide if the error message should be corrected.

Thank you very much for restoring a functional local dev environment.

1 Like

Ah excellent stuff.

Aye, 404 is still a pain at the mo (and not being reported as such in the browser). I need to get dug into electron to see what’s going on there.

Glad you’re going again! :surfing_man: