"Cross-origin resource sharing (CORS) is a policy that prevents a webpage from connecting to a server, unless that server has given that webpage permission to connect."
CORS only applies to requests for restricted resources like fonts or XHR requests that aren't simple GETs and POSTs.
"So, while this is typically not possible: foo.com/index.html ---GET---> bar.com/pic.jpg"
Typically this is possible. Images, stylesheets, scripts, iframes, and videos aren't subject to CORS.
"You can solve it by routing the request through your host server: foo.com/index.html ---GET---> foo.com ---GET---> bar.com/pic.jpg
Not necessary, the client's browser can get bar.com/pic.jpg just fine all by itself.
"Pinning tools like Hashbase and Homebase help keep dat:// sites online"
If you publish a dat archive, how do you notify Hashbase to pin it? Can you do it through dat?
To keep my dat alive with Hashbase, do I have to set up an account, provide and confirm an email address, link a credit card, etc.?
Are centralized servers, financial institutions and surveillance all required components of the anonymous, decentralized, peer-to-peer web?
> Typically this is possible. Images aren't subject to CORS.
You're right, that was a misleading example. I changed it to data.json to be more clear.
> If you publish a dat archive, how do you notify Hashbase to pin it? Can you do it through dat? Does it require setting up an account on Hashbase, providing an email address, linking a credit card, etc.?
The "Pinning" system is very similar to Git remotes. You can pin using any endpoint that complies with https://www.datprotocol.com/deps/0003-http-pinning-service-a.... So, similar to a git remote, you do need some kind of authentication with the pinning service - unless somebody writes one that's open for anybody to push to.
The UX flow will be similar to a git remote as well, you use an HTTPS to tell the server to sync the dat. So, it's an explicit user action.
>> Typically this is possible. Images aren't subject to CORS.
> You're right, that was a misleading example. I changed it to data.json to be more clear.
CORS doesn't preflight GET, POST or HEAD methods unless they have custom headers or content-type other than application/x-www-form-urlencoded, multipart/form-data or text/plain.
So a simple GET bar.com/data.json works just fine in today's browsers.
In the absence of CORS header configuration on the target site, you can't use XHR or Fetch to get anything from a different domain. It doesn't matter if it's JSON, an image, or plain text.
To some extent, you're conflating some of the requirements to avoid preflighting with cross-origin requests simply being allowed, and they're not the same.
I'd be happy to be corrected on this, but here's what I understand:
While fetch doesn't preflight for GET, it does require an Access-Control-Allow-Origin header. You can specify `no-cors` in the mode to circumvent this, but then you cant access the response body (https://developer.mozilla.org/en-US/docs/Web/API/Request/mod...)
or content-type other than application/x-www-form-urlencoded, multipart/form-data or text/plain.
application/json is a content-type other than application/x-www-form-urlencoded, multipart/form-data or text/plain, and thus a request for it will fail unless the required CORS headers are present
There's a couple issues with your comment: first, the restriction you're talking about is related to preflighting, not to whether requests are allowed at all.
Additionally, you're thinking about the "wrong" Content-type header: the limitation you're mentioning about urlencoded and so on is a limitation on request headers, not response headers.
The CORS headers are required for the GP's described request to succeed, but not for the reasons you give.
> Are centralized servers, financial institutions and surveillance all required components of the anonymous, decentralized, peer-to-peer web?
Servers and financial institutions will never go away, no matter how hard we try. I'm hoping that we can make surveillance go away by sharing much less data with organisations who rely on surveillance to survive.
Hashbase is not "centralized" in the sense that you are always free to choose a different provider of its hosting services. You can host your own Hashbase: https://github.com/beakerbrowser/hashbase
You can even choose multiple providers at once, providing you with resilience in case one of your chosen providers violates your trust, eg. by losing your data or using it to spy on you.
> CORS only applies to requests for restricted resources like fonts or XHR requests that aren't simple GETs and POSTs.
CORS applies to XHR. Including GETs and POSTs, and including fetching images over XHR.
There's some other sibling comments here discussing preflight requests, which it sounds like you might be referring to, but CORS is not limited to just preflight requests.
Sure you can, you can make any request you want without CORS, the content is just opaque to you (for example you can display an image but not manipulate its pixels).
You do this for example with `fetch('./any-resource', {mode: 'no-cors'})`.
You can then for example do a `.then(x => x.blob())` and then use the resulting blob as an image.
> If you publish a dat archive, how do you notify Hashbase to pin it?
This is provided by hashbase in their ui. Sign up for an account and add your dat. It is email based, no credit card/address unless you go over the data cap.
This is a little backwards, the goal of CORS isn't just to protect the _user_ it is also to protect the _third party website_.
All it takes for a website to opt-in to this is just adding a single header - it's possible for bar.com to allow the request from foo.com by opting into it.
CORS only applies to requests for restricted resources like fonts or XHR requests that aren't simple GETs and POSTs.
"So, while this is typically not possible: foo.com/index.html ---GET---> bar.com/pic.jpg"
Typically this is possible. Images, stylesheets, scripts, iframes, and videos aren't subject to CORS.
"You can solve it by routing the request through your host server: foo.com/index.html ---GET---> foo.com ---GET---> bar.com/pic.jpg
Not necessary, the client's browser can get bar.com/pic.jpg just fine all by itself.
"Pinning tools like Hashbase and Homebase help keep dat:// sites online"
If you publish a dat archive, how do you notify Hashbase to pin it? Can you do it through dat?
To keep my dat alive with Hashbase, do I have to set up an account, provide and confirm an email address, link a credit card, etc.?
Are centralized servers, financial institutions and surveillance all required components of the anonymous, decentralized, peer-to-peer web?