SAFE Browser Fetch API best practice

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


@latch 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: https://www.electronjs.org/docs/tutorial/security#5-do-not-disable-websecurity

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

@joshuef

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.

@latch 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
https://github.com/joshuef/safe_browser/tree/AccessControlHeaderBranch and you can see the commit here to enable this. I think should get us around the CORS issue.


In general @latch 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:

3 Likes

@joshuef

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

With

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

@joshuef

That solved it, thank you.

1 Like

great stuff

@joshuef

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. https://www.iana.org/assignments/media-types/media-types.xhtml is an example of such a list, https://www.digipres.org/formats/mime-types is another, and there are others.

Here is the list of what’s supported @latch, https://github.com/maidsafe/safe-api/blob/master/safe-api/src/api/xorurl_media_types.rs#L50-L57, 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…?

2 Likes

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.

@joshuef

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

@joshuef

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: https://github.com/maidsafe/safe-browser/actions/runs/179750004

1 Like

@joshuef

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

@joshuef

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

@joshuef

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:

2 Likes