Closed benjaminvanrenterghem closed 4 years ago
Thank you for this suggestion. This has been implemented in version 583, and it is deployed to https://client.nyzo.co.
Version 583 is expected to be released tomorrow.
Version 583 has been released: https://tech.nyzo.co/releaseNotes/v583.
@n-y-z-o seems like this is still an issue. https://client.nyzo.co/frozenEdge for example does not return the Access-Control-Allow-Origin=* header.
Likely some glue code missing between layers.
Also, after a quick look it seems the client could almost be able to return proper Json, there is code already to return such payload (with application/json Content-Type), just this is apparently not used.
It would be great to either
I did not found an existing way of switching to Json. Being dependent of custom formatted html to extract data on the client side is a repeated pain.
All of the endpoints automatically render as HTML and as JSON. The Access-Control-Allow-Origin=*
header is set for all API endpoints.
For any endpoint, prefix with /api
to get the JSON version. In this case, it would be:
Awesome, missed that!
Thanks!!!
This is a proposal to add a **Access-Control-Allow-Origin=*** header to the API endpoints. This would allow a wider variety of applications to use the API.
While a browser extension may be an exception to the rule in that it allows such requests to take place (and it is peculiar that it does), most modern day browsers actively enforce the CORS policy and local requests can't be made to the API endpoints.
On the right, the request from the Nyzo tip extension, which doesn't get blocked by CORS policy. On the left, the request from a local index.html file, which does get blocked by the CORS policy.
I made sure to use the same XMLHttpRequest structure, copied over from the extension, but the results do differ.