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
GitHub - joshuef/sn_browser at AccessControlHeaderBranch 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 
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 
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:
That solved it, thank you.
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. Media Types is an example of such a list, All known MIME types is another, and there are others.
Here is the list of what’s supported @anon78698497, 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…?
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 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 - #5 by joshuef 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?
Absolutely. This completely slipped my mind. Will get into that now
A beta build has been fired up with this fix in: https://github.com/maidsafe/safe-browser/actions/runs/179750004
Thank you. I’ve tried 0.18.0-beta.0 and the error remains.
Oh really? 
hmmm.
Looks like it missed the server side use of the updated headers in my cherry-pick there 
Updated beta.1 on the build
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. 
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.
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! 
