No SAFE-DOM-APIs on localhost?

[gnunicorn]

Heyah,

it appears that though the window.safe*-APIs are made available on all safe://-URLs, I can't access them from http://localhost nor the file-system, which makes this really inconvenient for development :( .

Any chance we can whitelist localhost for the APIs?

[joshuef]

Hey, @gnunicorn I hadn't considered that, and it's a gooood point. I'll look into getting this sorted out. I think it's a simple matter with beaker-plugins. If it is, it'll follow when I've gotten your PR in.

Thanks!

[gnunicorn]

So, this turns out to be a little more complicated than initially expected. I thought I could just remove the internal: True-flag from the WebAPI definitions in safe-beaker-plugin, but it appears that beaker maps them into the protocol defined in the plugin, too. So that isn't enough.

Instead I also had to add the http protocol in the beaker-plugins protocol sections, too, like so:

    protocols: [ safeProtocol,
        {
            scheme: 'http',
            label: 'Localhosting',
            register: function(){}
        }
    ],

That is clearly not gonna work for our case, as this would expose the SAFE-DOM-Elements on all http-URLs. It works for me for now for the development environment, but we gotta find a different solution overall :( .

[joshuef]

@gnunicorn yeh, it's so so clear cut for beaker and exposing the APIs.

For now, for development I think perhaps we'll need to make a shim for safe-js. We could look at building out a polyfill with the compiled code that will check/create the window APIs if they dont exist, so for dev you might just need to include that:

<script src="<safeShim location> type="text/javascript"/>

and the pollyfill would simply do something like:

    var polyfillSafeAuth = { 
    // this would be the actual safe-js functionality, natch
        authorise : function()
        {
            console.log( 'polyfilled auth method!' );
        }
    }

    if( ! window.safeAuth )
    {
        window.safeAuth = polyfillSafeAuth;
    }

This allows for development with the same API methods (via file: or http://localhost, or indeed http), and would give you the added bonus of seeing the network requests which might aid debugging.

For production build of safe sites, you'll just be removing the polyfill.

What do you think, @gnunicorn ?

[joshuef]

I've implemented a polyfill, which is available in the npm package as of safe-js 0.1.3.

This will add the window.safeXXX objects so you can fire in with development in your chosen environment without the safeAPI restrictions from beaker.

[gnunicorn]

@joshuef that's a good intermediate solution. However, the latest beaker from master currently blocks my localhost requests through CSP headers:

Fetch API cannot load http://localhost:8100/0.5/auth. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8081' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

[gnunicorn]

Do I have to explicitly add the Access-Control-Allow-Origin-header to my localhost for this to work?

[frabrunelle]

@gnunicorn I think you need to go in the "BeakerDev" menu and click on "Toggle WebSecurity for new tabs".

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.)

Source

[gnunicorn]

@frabrunelle that doesn't have any effect. Still having the same issue.

[joshuef]

@gnunicorn you're testing this in a newly opened tab after toggling the option? As it does not affect currently open tabs.

[gnunicorn]

@joshuef dunno why it didn't work, does now. Would be nice to have an indicator after switching – I have things running for a long time, with laptop sleeps in between and it's impossible to remember ;) .

[joshuef]

Grand. That I can add to the list: #12