CORS difference from Beaker

[da2x]

Beaker supports loading dat://site2 from the context of dat://site1.

Cliqz blocks these requests with an Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at dat://site2/example.file (Reason: CORS request not http). error message.

So is this a security issue in Beaker? or a deliberate change from HTTP? or is it just an issue with dat-webext and Cliqz?

Demo app: dat://rss-reader-pfrazee.hashbase.io/

Thoughts, @pfrazee?

[pfrazee]

Beaker uses a permissive CORS on dat responses right now. The RSS reader was an example of why I felt that was important.

[da2x]

Is that by design because Dat origins are assumed to be public and hold no secrets? Is this something you expect to remain unchanged? Should it be defined as a standard for Dat resources?

I thought about extending dat.json to include a access_control.allow_origin property similar to the content_security_policy property. However, it’s probably better to use something that can be applied to individual files and not an entire origin.

What about using a special file as a control mechanism? So for example example.file.allow-cors. No file or a zero-length file means none, or the file can include either * or any to mean any origin, or list one origin per line for more granular control. Lines starting with # are comments.

Is that something that could work for Gecko, @sammacbeth?

A more generic solution could be using a example.file.http that lists one HTTP header and value pair per line.

[pfrazee]

At the moment, the assumption is that if you have the Dat's URL, you're able to read it. I expect us to build out a more sophisticated ACL system but I want to make sure we're thinking it through hollistically. For instance, it doesn't make a lot of sense to introduce CORS controls if they don't also apply to the DatArchive read operations.

[sammacbeth]

We inherit the CORS policy from Firefox, but this is configurable by the protocol handler AFAIK. The nsIProtocolHandler flags in libdweb should control how content is treated: https://github.com/mozilla/libdweb/blob/master/src/protocol/router.js#L502 .

I tweaked these flags for this extension to allow third-party origins to load in dat pages: sammacbeth/libdweb@fd8c687
I'm not sure if it would be possible to actually disable CORS for dat requests as beaker does. In any case, the DatArchive can be used for these use-cases.

[pfrazee]

We don't actually disable CORS. We just respond with a * on the header.

[glowkeeper]

I think I'm seeing the same issue. I'm running the following dat on the MAC build of Clickz Latest:

dat://795f83fa1356cd7d00e5cfe8f1a93f32c55127684c6fc4cb8ff89a32e000016b

That is a frontend to some contracts running on the Ethereum Rinkeby Test Network, so it relies on MetaMask to inject a web3.js instance that points to Rinkeby. Unfortunately, no matter what I do with MetaMask, my app' thinks it's on the Ropsten network, and I get these errors:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://127.0.0.1:8545/. (Reason: CORS request did not succeed).

Meanwhile, is there anything I can do to get Clickz Latest working for dat relying on MetaMask to do the right thing? What's DatArchive, mentioned above?

[sammacbeth]

@glowkeeper This is the same as the browser's standard cross origin policy. You can send the Access-Control-Allow-Origin header from the third-party server to fix the error.

i.e. on your server at 127.0.0.1:8545, send the header access-control-allow-origin: dat://795f83fa1356cd7d00e5cfe8f1a93f32c55127684c6fc4cb8ff89a32e000016b and it should work (for that dat page only). You can also use * to accept requests from any origin.

[glowkeeper]

@sammacbeth

i.e. on your server at 127.0.0.1:8545, send the header access-control-allow-origin: dat://795f83fa1356cd7d00e5cfe8f1a93f32c55127684c6fc4cb8ff89a32e000016b and it should work (for that dat page only). You can also use * to accept requests from any origin.

Forgive my ignorance, but I'm pinning that dat via Homebase - how do I send that header?

[sammacbeth]

@sammacbeth

i.e. on your server at 127.0.0.1:8545, send the header access-control-allow-origin: dat://795f83fa1356cd7d00e5cfe8f1a93f32c55127684c6fc4cb8ff89a32e000016b and it should work (for that dat page only). You can also use * to accept requests from any origin.

Forgive my ignorance, but I'm pinning that dat via Homebase - how do I send that header?

The JS in the dat you linked is trying to content a webserver at http://127.0.0.1:8545/. It is that server that should send the header.

[glowkeeper]

The JS in the dat you linked is trying to content a webserver at http://127.0.0.1:8545/. It is that server that should send the header.

That must be the web3.js library trying to open a default instance to access a private (test) blockchain, such as that provided by Ganache. In other words, it's not a webserver and it's not code or service under my control.

Sounds like I might be, er, f****d in trouble....

Also sounds like I need to speak to the good people at web3.js since it appears their library's default behaviour is breaking my dat on Clickz. That's a shame...

ps. what's puzzling is that same dat works seamlessly on vanilla Firefox with the dat P2P protocol extension installed.

[glowkeeper]

ps. I should mention that web3.js gets injected by MetaMask...

The JS in the dat you linked is trying to content a webserver at http://127.0.0.1:8545/. It is that server that should send the header.

That must be the web3.js library trying to open a default instance to access a private (test) blockchain, such as that provided by Ganache. In other words, it's not a webserver and it's not code or service under my control.

Sounds like I might be, er, f****d in trouble....

Also sounds like I need to speak to the good people at web3.js since it appears their library's default behaviour is breaking my dat on Clickz. That's a shame...

ps. what's puzzling is that same dat works seamlessly on vanilla Firefox with the dat P2P protocol extension installed.

[glowkeeper]

Aha! This is indeed a problem with web3.js, and it'll be fixed with the imminent release of v1.2.2...