And the usual right click menu too (copy, paste, delete,…). In a browser is something basic.
Hmmm, these should be in there in. (They are at least programmed into beaker)… Which mean’s there’s some bugging somewhere.
I wasn’t aware of this, so I’ll scope out and PR any fix I find. I’m assuming you’re on linux @happybeing, aye? And @digipl , too?
On another note… is it possible to checkbox in discourse (a la github? ) Anyone know?
you can use the emoji (:white_check_mark:
). that’s what the Discourse team is doing
Update to 0.3.2:
This features a more robust ‘safemode’ toggle, including a navbar icon showing that you are on the safe network exclusively. This can be toggled by clicking the icon, or going into the File
menu. This will reload all tabs upon toggle, blocking/enabling insecure (non safe) content.
Other minor changes include improved appveyor builds (only one link needed now!) and improved file naming.
Local Development
To aid local development the safejs now contains a polyfill for window.safeXXX
methods found in beaker, so you can more easily develop on localhost
or file
urls in the browser (where beaker’s safejs
methods are not available.). These methods will trigger calls to localhost:8100
in the browser, but allow you to use the same interface as if you were developing with the browser’s safe API methods.
This leads onto another problem, of cross-origin requests. For now you can also disable CORS checks via the Beaker Dev Menu
, this is an advanced feature that disables security checks on new tabs, so be aware you’re no longer safe if you use this. (This feature will only be available in dev mode once I’ve got the build scripts adapted.)
It’s worth noting though, that the best way to access the network is via the window.safe
methods (via the polyfill), as any cross origin ‘localhost’ calls will be blocked by the browser for users. Disabling security checks is purely a convenience for local development, do not rely on this for anything in production on the network.
10 posts were split to a new topic: Beaker v0.3.2. + SAFE-JS’s NFS: Unexpected token a in JSON at position 0
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
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).
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
Is there a way to check the version in Beaker? If not can you add it. Thanks
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…
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)