Open whoImT opened 8 months ago
Yes, we kind of decided we didn't want CORS for NGSi-LD. The OPTIONS method is supported but not "Full CORS". This was quite some time ago and not really my decision. I don't recall the reason for not supporting CORS, but, I have an idea on who might. A colleague of mine in the FIWARE Foundation, Jason Fox. I'll have him post here shortly
Orion "classic" i.e. the NGSI-v2 broker from Telefónica, has made the decision to support CORS, and I assume that this occurred before the Orion-LD fork, hence the reason why Orion-LD may still support it over the /v2
endpoints. However, when last discussed by the ETSI committee, a common instantiation of CORS support was not seen as necessary for NGSI-LD context brokers themselves. You can still use existing solutions like CORS Anywhere or the NGSI-JS library if you find this necessary. Wirecloud uses NGSI-JS for example.
The FIWARE NGSI-LD Tutorial App avoids this by shifting requests server-side rather than running directly from the browser.
Orion-LD does support the CORS preflight request using the OPTIONS verb, but declines to return Access-Control-*
Headers since it does not offer CORS. NGSI-LD context brokers are defined to be security agnostic and therefore should not be bound to a specific security paradigm. Support for OPTIONS is not defined within the ETSI NGSI-LD Specification since NGSI-LD is not supposed to be bound to a specific binding like HTTP only, but is obviously good practice for an HTTP implementation of the API.
I assume the reason Telefónica Orion supports CORS is that NGSI-v2 brokers are commonly used in isolated systems and therefore a flag switching on one specific security mechanism can make more sense. NGSI-LD broker are more likely to be used exchanging data across dataspaces and are not usually accessed from a browser directly.
When you enable CORS for all origins request to .../v2/ work with CORS but request to .../ngsi-ld/v1/ do not work