CORS, Content Security Policy and Access Control for SAFE sites

@ben

Added:
Header add Content-Security-Policy "default-src 'self'"

Stopped and started the server and indeed, blocked:
CSP14312: Resource violated directive 'default-src 'self'' in Content-Security-Policy: http://localhost:8100/auth. Resource will be blocked.

Took that CSP line out again, stopped and started and was allowed to approach Safe Launcher again. This was in Edge 14 (Microsoft Edge 38.14393.0.0)

Odd, default-src 'self' is already in the proxy.

Just to clarify, the setup is: you are hosting a file (the one you posted), which has an iframe to a file hosted on safenet/served through the safenet proxy?

Wait. That doesn’t appear to be the case though. Only that second file (from within the iframe) is then going through the launcher, am I correct? Well in that case, that’s the first place the CSP is currently returned and thus the other pages before aren’t protected by it. It’s rather odd that FF and Chrome block here, they shouldn’t.

But that isn’t realistic conditions: on safenetwork also your initial html and the iframed-html page would be served with CSP headers, thus eliminating the problem you are talking about. This only happens in the specific development setup you are having at the moment.


Either way, I feel even stronger about streamlining this now. The pages of your local system should be served with the same CSP-headers to create realistic conditions and avoid finding out about problems like these only after you deployed.

I agree, but also with the option to turn CSP off with a debug setting, not something directed at everyday users (like the difficult to access CORS control variable in Firefox etc.)

I’m now trying to locally run a safe web app and I’m running into this issue with launcher v0.10.0.
I tried with a local launcher as well, with “npm run dev” but it still doesn’t work. Is there a way to overcome this with the launcher? or what are my options?
I’m using safe-js, and either with or without the polyfill I see the same result.

1 Like

CSP is disabled on latest launchers, because there is no proxy anymore.

I think there might be a different problem, but it gets exposed as an “CSP” problem - dunno why, but the browser does that sometimes. Take a close look to the actual error message in the object in the console and the http request.

Just to check: have you “disabled web security on new tabs” and opened a new tab?

If not that would cause this.

EDIT: Oh, you’ll need to be running a local Beaker too, with NODE_ENV=devel or you won’t get that menu option!

2 Likes

Thanks a lot @ben and @happybeing!
It worked after “disabling the web security for new tabs” as suggested by @happybeing (I’m sorry I wasn’t aware of this option :blush:). Although, I was able to do it with an AppImage of Beaker (v0.4.0-5).

4 Likes

Although, I was able to do it with an AppImage of Beaker (v0.4.0-5).

That sounds like a bug! @joshuef?

Huh? I’m confused… It works or?

If not, please try with the latest version (0.4.2 stable) Releases · joshuef/beaker · GitHub , dev mode with NODE_ENV=development as @happybeing noted.

Let me know how you get on!

1 Like

My understanding is that @happybeing was suggesting this option shouldn’t be available when running the AppImage but only if you build it with NODE_ENV=devel.

Aha. Yes that makes sense :smiley: Totally read this wrong.

@happybeing this is only available with the AppImage? Or all linux builds?

Ask @bochaco - I haven’t tried it. I’m only using source!

1 Like

I’ve been using the AppImage v0.4.0-5 x64 only, and it works, i.e. I’m able to use safe-js polyfill to connect to the Launcher, running my app locally with nodejs.

As an aside comment, for those devs out there, I also managed to do the same running my app within Electron.

2 Likes