Never mind ... I had a problem with the permissions.json ;) Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat Microsoft MVP on Windows Embedded & IoT Microsoft Azure Advisor
To: hono-dev@xxxxxxxxxxx From: ppatierno@xxxxxxxx Date: Fri, 29 Apr 2016 18:58:57 +0200 Subject: Re: [hono-dev] Redundant(?) properties in API messages
If you see here :
https://github.com/eclipse/hono/blob/master/server/src/main/java/org/eclipse/hono/authorization/impl/InMemoryAuthorizationService.java
the hasPermission() calls the hasPermissionPerTenant() and the resource.getDeviceId() is null so false is returned.
Sent from my Windows Phone
I am sorry but I don't get it. When the client connects we check whether it is authorized to publish data for the tenant (based on the target address during link establshment). Then, once the link is established, we check for every message (based
on the message's to field) whether the client is authorized to either write data for the specific device at hand or for the tenant the device belongs to. At least that's the intention ... did we not get it right? Maybe you can be a little more specific what
you think should be different :-)
Kai
I still see a problem on authorization side with the current TelemetryClient example because the hasPermission() method searches for the deviceId inside the address that from the sender client is /telemetry/myTenant (the device id is still in the "to" property).
Sent from my Windows Phone
Exactly. And what is your concern regarding this?
Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor
Subject: Re: [hono-dev] Redundant(?) properties in API messages
Hi Paolo,
TelemetryClient uses "telemetry/myTenant/4711" as address in the messages it sends. We ditched the application properties because we thought it would only contain redundant information.
Current master fully implements all of this. Maybe you need to rebase your local master onto origin/master to see it?
Kai
Hi Kai,
I'm digging into the last bits of Hono and I see you have already implemented the "one sender for tenant" sematic in order to connect to the dispatcher.
I still see a problem on authorization side with the current TelemetryClient example because the hasPermission() method searches for the deviceId inside the address that from the sender client is /telemetry/myTenant (the device id is still in the "to" property).
Is it just because the TelemetryClient isn't aligned in terms of source code ?
Thanks,
Paolo.
Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor
>
> On 27/04/16 14:14, Hudalla Kai (INST/ESY1) wrote:
> > We will now try to use a sender (with target address) per tenant when forwarding the telemetry messages to the dispatch router.
> >
> > However, since I think that being able to authorize at the device level (when receiving telemetry data) as well, it would be great if the dispatch router would at some time support what you promised :-)
> >
> > Any chance for that?
>
> Yes, I think there will be more flexible routing at some point.
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________ hono-dev mailing list
hono-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev _______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
|