search

FIWARE / context.Orion-LD

Context Broker and CEF building block for context data management which supports both the NGSI-LD and the NGSI-v2 APIs
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.06.01_60/gs_CIM009v010601p.pdf
GNU Affero General Public License v3.0
50 stars 43 forks source link

X-Auth-Token not forwarded? #553

Closed wagmarcel closed 3 years ago

wagmarcel commented 4 years ago

I am trying to use the X-Auth-Token header with of Orion-LD. I executed the following steps:

  1. Submit a new object, e.g. urn:ngsi-ld:object1 to the broker via the POST /ngsi-ld/v1/entities endpoint
  2. Register a context provider for property1 of object1 via the POST /ngsi-ld/v1/csourceRegistrations/ endpoint to myserver
  3. Query entity via the GET /ngsi-ld/v1/entities/urn:ngsi-ld:object1 endpoint.

What I see then is that orion-LD is requesting property1 from myserver, so the request is successfully forwarded. Howerver, when I add the X-Auth-Token header to step 3. it is not forwarded to myserver. I tried the same with the orion ngsi-v2 server and the forwarding of the X-Auth-Token header worked.

Can anyone tell me whether this is a known issue?

kzangeli commented 4 years ago

The forwarding in Orion-LD is independent of the forwarding mechanism used by Orion. It's still being defined in ETSI ISG CIM and what you have found is merely a proof-of-concept that was implemented in Orion-LD and one of the iot-agents.

And yes, the HTTP header you mention should of course be included in the forwarded request (that one and more headers).

I will try to implement this specific header some time this week.

kzangeli commented 3 years ago

github auto-closes issues ... Reopening it. @wagmarcel , please re-test and close the issue if satisfied.

Wait, you may need a docker image to test ... I've created a new image and pushed to dockerhub, with the tag "latest"

wagmarcel commented 3 years ago

Thanks @kzangeli ! I tested the latest image and the scenario described above worked for me! I am impressed by the speed of fixing this issue :-) Now I can continue my evaluation of Orion-LD (I am currently exploring integration with a project using Keycloak). I have another question though: I would like to use the x-auth-token forwarding also for subscriptions, e.g. when I send attribute updates, I'd expect the subscription request also to forward the x-auth-token. I think your patch only solved the ContextSourceRegistration (which is great!) but not the Subscription, right?

kzangeli commented 3 years ago

You're in luck!

I implemented exactly what you need a few weeks a ago on request from another user. It's a pretty new feature, I think we added it in the 1.3.1 release of the API.

In short, when creating your subscription, you can ask the broker to use any number of extra HTTP headers for the notifications originating from the subscription.

Just put the header name and its value in the array notification::receiverInfo (a key-value object) of the subscription. As an example, see the following payload data in the functional test I used to implement this feature:

https://github.com/FIWARE/context.Orion-LD/pull/519/files#diff-8d8a885b14b1074e0d68dca57e38cdd2115fba05d8af1568082d5f846699b395R56

wagmarcel commented 3 years ago

Thanks! That sounds exactly like something I need. Just checked it on latest container and looks good for me! Then I'll close the issue.