cliqz-oss
CORS difference from Beaker
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?
Beaker uses a permissive CORS on dat responses right now. The RSS reader was an example of why I felt that was important.
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.
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.
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: https://github.com/sammacbeth/libdweb/commit/fd8c68712eb13d7b772aa418f0daeb8072e212d9
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.
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?
@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.
@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
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
datvia 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.
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.
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
datonClickz. That's a shame...ps. what's puzzling is that same
datworks seamlessly on vanilla Firefox with the dat P2P protocol extension installed.
Aha! This is indeed a problem with web3.js, and it'll be fixed with the imminent release of v1.2.2...