SAFE Beaker Browser - Web App Developer Discussions

General
1

A topic for developers of web apps to ask questions and discuss issues around how SAFE Beaker Browser supports the SAFE API and so on.

1 Like
2

@joshuef I’m trying to get my RS.js apps working in SAFE Beaker. This may be a bit premature :slight_smile: but I’m looking at this as a way to get these apps into the hands of community members to play with. Currently this is not possible, because once served from the alpha1 network, the CSP headers inserted by the Launcher web proxy break them. I can work around this for development, but I want end users and other devs to be able to see these examples without a special setup (turning off CORS checks in browser, customised launcher, hacking the launcher proxy, of having a local build of launcher etc.)

I’m probably jumping the gun… but is there a way to access the API within beaker? Just using normal http/proxy would be fine for now. I’ve tried just setting the endpoint to api/auth and so on, but this doesn’t work because somewhere SB is changing this to safe://myfd/api/auth (where ‘myfd’ is the public ID of the site). So I need a way to send a request to the launcher without the ‘myfd/’ in it).

That would be fine for the time being, would mean that to access my RS.js apps people would also download and test SAFE Beaker! :slight_smile:

UPDATE: I thought I’d poke around in SAFE Beaker and found the code that rewrites the URLs but that doesn’t seem to be my problem. Now I’ve tried doing requests from my app code to to SAFE API endpoint formats, and each hits a different CORS related error.

The following is for a SAFE website at safe://myfd (which is a remoteStorage.js app that works fine locally, but hits problems with the CSP headers in the launcher proxy when access from the alpha1 network):

  • http://localhost:8100/auth (as specified in the MaidSafe docs) produces app console output:
    XMLHttpRequest cannot load http://localhost:8100/auth. 
    Response to preflight request doesn't pass access control check: 
    No 'Access-Control-Allow-Origin' header is present on the requested resource. 
    Origin 'safe://myfd' is therefore not allowed access.
  • http://api.safenet/auth (as has been mentioned too) produces app console output:
    remotestorage.js:5276 XMLHttpRequest cannot load safe://api.safenet/auth. 
    Cross origin requests are only supported for protocol schemes: http, data, chrome, https.

I just want something ordinary users can use but am struggling with stuff I don’t really understand yet. Any hints, suggestions or hand-rolled solutions welcome :wink:

1 Like
3

Hey @happybeing, yeh, as noted over here you’re going to run into the same CSP trouble here for now. :frowning:

The URL rewrite wont, in the end, be how to access safe API requests, it will be via SAFEBB, window.safe calls (implemented via beaker-plugin setup). There’s nothing really usable as yet, but this will be my next point of call once I’ve cleared linux build issues.

Another suggestion might be for you to set up a domain to proxy this, or as @ben suggests, via [webpack proxy] (CORS, Content Security Policy and Access Control for SAFE sites).

Or:

I’d normally setup really basic nginx host to do this for webdev projects (as CSP is often an issue with localhost:port setups). Such that you create a new domain <happy> and proxy <happy>/auth to localhost:8100 so that it appears to live under the same host to the browser.

for example (from the nginx page above):

location /some/path/ {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://localhost:8000;
}

This does require some nginx setup, which I’m aware is another thing. But once setup, you’re pretty free to setup proxies as you want, and spoof certain urls etc to the browser to get around CORS/CSP problems.

Hope that’s helpful.

1 Like
4

Thanks @joshuef …showing my ignorance here, but are those suggestions for development, or ways of getting around CORS/CSP blocks for deployed SAFE websites? The latter is what I’m trying to fix, so if this achieves that I’ll dig further. I am fine with development though.

5

I think he was suggesting it for you development, but yes also it should work for that. Just creating your own proxy setup instead of using MaidSafe’s which currently blocks inline scripts / styles. And nginx is about as easy as Apache etc so it shouldn’t take long to get set up.

6

Yeh, sorry, this suggestion for development only.

For deployed sites I think we’ll need to wait for the less-strict CSP, or for an updated SAFEBB with the api setup and accessible so you’re not making such x-origin requests.

2 Likes
7

Anyone have any news on this?

8

I believe we can expect an update when the proxy is removed from the launcher, as this is what sets CSP at the moment.

1 Like
9

Cool! Didn’t know that was possible. Do you know how that will work?