Um, not sure if this is me but Beaker doesn’t seem to have injected the NFS portion of safe-js onto the window object:
EDIT: I’m using polyfill.js
4 Likes
Looks like a polyfill issue. Was missing 
New npm package coming your way!
Hey @joshuef, question like that if you got some time. How well is the code of the browser isolated against the code from a web page? Is there any way a web page can compromise the javascript that runs the browser? Would it be theoretically possible to run two webpages side by side and block them from seeing each others?
In electron there’s a background process and the main process, which are separated, but can communicate if needs be. The main process in beaker is the ‘window’, which manages all the pages. The pages themselves are isolate using webview elements, which are discrete chromium processes and the js cannot interact.
You can read more about [electron webview elements here] (http://electron.atom.io/docs/api/web-view-tag/). Electron documentation is really very good, although a bit of a rabbit hole.
But in short, two webpages cannot communicate through the browser, outwith of standard web interfaces, or the SAFE API (they could both write to a file to exchange data, for example).
6 Likes
0.3.3
This is a development release which addresses, @Krishna’s notes from the feedback thread about spoofing token’s in memory in beaker.
Now beaker/safe-js derives it’s token and storage from the host name automatically, meaning no two sites should be able to access the other’s data via supplying the same token.
This is implemented via a small check in safe-js. The token param of authorise is not needed for beaker, but mandatory for other js environments.
Questions:
Right now, in 0.3.3 safe browser is overwriting the vendor portion of the app packageData object. I think this is useful as the launcher displays the URL which made the request. Avoiding, perhaps, a site that pretends in the packageData to be another app.
This is certainly not ideal for cross-device apps (browser vs desktop vs mobile), so I was wondering, @Krishna, @frabrunelle do you think we can have an optional field for host to be displayed in the launcher, to clarify for ‘browser situations’ where exactly the request originates? (which could be optional for apps, but not for safe-browser sites?) Or is this, perhaps, overkill? Or even, moot, given the latest launcher discussions?
Download
1 Like
Is there a way to check the version in Beaker? If not can you add it. Thanks 
1 Like
I wanted to propose a window.SAFE.version, too. (just an array of the semver in use. like [0, 3, 3, 'dev'] – with the last optional of course, or an object {'major': 0, 'minor': 3, 'patch': 3, 'pre': 'dev'}) I think that’d be very helpful for ensuring you are using them right for multiple version…
3 Likes
That would be great, but I was meaning in the UI 
Yeh, good ideas. I’ll get this worked in 
Hi is this version just a test version perhaps?
I’m having lots of trouble working on my SAFE web apps with it. SafeEditor doesn’t work, many of my bigbang sites don’t, and the only page I can really get working is my APP ZERO (all on alpha).
Really wanted to give a shot at working on a web-app version of the email software, but the firefox proxy was taken down and I can’t get anything to work right in the SAFE Browser so I’m feeling kind of stuck? (win/lin)
@WhiteOutMashups have you converted to using the version of safe-js bundled into the window object in the safe browser? or are you still trying to get calls to localhost to work?
The latter will not work on live safe: sites. You should be moving towards accessing the safe-js methods such as window.safeAuth.authorise().
You can test these against a localhost test site in the current 0.3.3 version of beaker (as noted here)
1 Like
Ok fine, but just so I understand, everyone’s moving in that direction for web apps since the proxy was removed? It’s the main option now, moving forward? That’s fine, but it means all web app devs will be pretty dependent on safe-js to stay current right? Lots of added pressure on you, sounds like, and I’m just remembering making SAFE-FS versions and we were waiting on safe-js updates each time we wanted to move forward
not saying anything bad against you, it’s totally human and totally understandable to not be 100% updated always, but it just seems to be moving back in that direction, yes?
side question, this means like in the JS DOM? That’s how it gets around the need for a proxy?
Thanks @joshuef , tried more just now, got a little farther, left you some questions in the other forum here.
I have a local version of APP ZERO I’m making with safe-js, so I have a folder on my desktop with all the safe-js files, and my index.html and this javascript file, all in my desktop folder.
All the files are together, so the safe-js parts should be working right? I just can’t seem to get the auth part working (which is what APP ZERO is all about for anyone not following it)
Any and all help from anyone is very very much appreciated! Looking to get started with safe-js 
Sorry if that’s too many questions…
Just want to understand auth in safe-js 
Maybe the tutorials will help here Will. I’m busy for now, but if you post your code I’m sure someone will jump in and help.
I’ve responded over there.
RE: window, yeh, as in the window object available to any running js on a page. You can access it via the console in the browser to test things out.
To get safe-js in beaker, via window, the site HAS to be uploaded (for security), but you can shim the window functionality so you can test locally, and just remove the polyfill for going live.
Heh, yeh, a lot more safe-js pressure im working on improving its error flow and promisey-ness right now. So it should be smaller/smoother.
If anything is unclear in the docs, PRs are super welcome.
And I think more things like what you’re doing, more tutorial projects and examples will also help, * a lot*. So thanks for going through the pain 
3 Likes
0.3.6-0
Pre release of 0.3.6 can be found here: https://github.com/joshuef/beaker/releases/tag/v0.3.6-0
This features the updated safe-js with better promise rejection and error parsing to give an informative error instead of the uninformative 400 Bad request.
This has only been updated for the ‘classic’ APIs so far.
2 Likes
Dev Update
It’s been a wee bit quiet on the Safe Browser updates as I’ve been knee deep in making some fundamental changes to enable the last stretch goal to be met. So I’m happy to say that I’ve got a working prototype hooking up beaker’s data storage APIs to the network
The OverrideStorage Branch is still in heavy development (aka: pretty rough around the edges), but it enables SAFE storage of sitedata and settings APIs to the network. As well as retrieval of the same settings from the network on launch.
This has been a complicated process, working around some specifics of beaker, but I’ve got something going that doesn’t interfere too much with the core beaker code. And now that the patterns of internal data storage and retrieval are set, it’ll be a cleaner process getting the remaining APIs hooked up. (Which I’d hope to do this week).
There’s also a few extra things that are coming as part of this next batch of changes ( I won’t offer any built packages as yet, as everything needs to be solidified, tested and tweaked):
Add launcher detection (helper in safe-js), and appropriate notification.: There is now a SAFE Status page giving an overview of launcher status (Currently hacked together, but working as a POC).
Safe network sync for browser data. as noted above
- Setup some helpful default ‘favourites’ for safe This will be bundled with an updated Bookmarks API using the safe network… all we need here is a list of default sites
- ensure production environment used for builds & remove BeakerDev menu: This will need to be implemented as part of this update to ensure things are clean and clear for production users (removing some ‘dev’ portions of the interfaces.
And once that’s all in, I’ll be free to scope out the usability issues and other bugs currently up there (feel free to add more, or PR with changes !)
SafeJS
I’ve also squashed a couple of safejs issues, which will be coming to the browser with the next big release. Highlights include:
- authentication has been simplified (no token needed) and where needed, beaker specifics have been wrapped into the plugin (https://github.com/joshuef/safe-js/issues/10 and https://github.com/joshuef/beaker-plugin-safe/tree/WrapAuth)
- NFS in the polyfill has been fixed (https://github.com/joshuef/safe-js/issues/12) you can grab updated polyfill with the latest NPM package.
- createOrUpdateFile - a method has been implemented to allow for updating of files as this is currently missing from the api (as I understand) https://github.com/joshuef/safe-js/issues/6
I’ll continue working on safe-js as we go to improve it, so thanks for those catching bugs and pushing the repo forwards! (@happybeing, @ben)
Technicalities
For those interested in such things, I’ve worked around beakers’s sqlite dependency by implementing a redux store in the app for each beaker API. This makes things (for me at least… someone who does not like sql ) cleaner and clearer and it also gives us a really simple object to be saving to the network (via using store.getState() whenever we update a change.
It also provides a simple and clean event listener to check for changes on pages. Although getting this to work in beaker which isn’t built in a fluxxy manner, has been a bit of a pain, it is all doable, which is good.
Questions/Thoughts
Some things I’ve come up against but don’t have an answer to, yet:
-
browser
authToken… this can be used to auth as the browser on the network. Currently it’s saved nowhere for obvious reasons. This means a lot of re-auth with the network (at least when you’re testing ). This isn’t necessarily a bad thing… It does make me wonder if any authenticator could have an ‘approve automagically’ option for trusted apps…? -
saving data to the network: Currently I’m writing/fetching a whole file. I can see this being a costly exercise in terms of PUTs (especially as an update currently needs to remove/put a file on every update. I’m wondering if this should simply be done on an interval, instead on every update of state (as happens right now). I’m also wondering if, via new data structures on the network, there might be a better way… @Krishna @ben any thoughts there? (I haven’t had a chance to scope out the latest examples of data storage yet, so I’m pretty clueless. But I’m hoping to dive in once base Sync is done. )
-
default safe sites - As noted above, I’ll be implementing new base ‘favourites’… what should they be?
5 Likes