observable sends origin and referer request headers. just use that for restricting your data end points to observable notebooks via access control allow origin response header without opening up wide for the world with * (not recommended unless your data enpoints are truly public for any web client to consume, and those are best done with user/app keys to secure and control that data flow )
No the last question but there is a format difference in the examples:
For our API it the JSON request looks like this:
and for the examples it looks like this:
The first I associate with a query type and the second a file request is that going to make a difference when I do :
data_x = d3.json(“https://mwshovel.pythonanywhere.com/dirt/beaches/Vevey/?format=json”)
Ok this is settled for the case “CORS Allow all” I published the notebook with the resulting query. Very cool !
Now for the case of just observable and our domain. I do not understand your reply. In django I can:
A list of regexes that match origin regex list of origin hostnames that are authorized to make cross-site HTTP requests. Defaults to
 . Useful when
CORS_ORIGIN_WHITELIST is impractical, such as when you have a large number of subdomains.
CORS_ORIGIN_REGEX_WHITELIST = (r’^(https?://)?(\w+.)?google.com$’, )
This seems like it may be appropriate.
Probably something like this:
CORS_ORIGIN_REGEX_WHITELIST = (r’^https://(\w+.)static.observableusercontent.com$’, )
that or you can just pull Referer and origin request headers, check for .observableusercontent.com domain and repost them in allow access control origin response header or issue 401 or 403 response instead for web clients from other sites.
not sure how it’s done in django, but I bet similar to express.js and others you have programmatic access to request/response pipeline and headers.
I would still recommend user/app key route for public data api’s since those request headers can be easily spoofed too.