Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Redundant(?) properties in API messages

Never mind ... I had a problem with the permissions.json ;)

Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



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

From: Kai
Sent: ‎29/‎04/‎2016 18:53
To: hono developer discussions
Subject: Re: [hono-dev] Redundant(?) properties in API messages

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 

On Fri, Apr 29, 2016 at 6:43 PM Paolo Patierno <ppatierno@xxxxxxxx> wrote:
As I said ...


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).

Am I lost something ?


Sent from my Windows Phone

From: Kai
Sent: ‎29/‎04/‎2016 18:41
To: hono developer discussions
Subject: Re: [hono-dev] Redundant(?) properties in API messages

Exactly. And what is your concern regarding this?

On Fri, Apr 29, 2016 at 6:25 PM Paolo Patierno <ppatierno@xxxxxxxx> wrote:
Hi Kai,

I forked this morning and now on the Hono master here :

https://github.com/eclipse/hono/blob/master/example/src/main/java/org/eclipse/hono/example/TelemetryClient.java

I see :

String address = String.format("telemetry/%s", tenantId);
ProtonSender
sender = connection.createSender(address);

but I see :

String address = String.format("telemetry/%s/%s", tenantId, deviceId);

only where it is used as "to" property in the readMessagesFromStdin().

Paolo.

Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



From: sophokles.kh@xxxxxxxxx
Date: Fri, 29 Apr 2016 16:16:20 +0000
To: hono-dev@xxxxxxxxxxx

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 

On Fri, Apr 29, 2016 at 6:01 PM Paolo Patierno <ppatierno@xxxxxxxx> wrote:
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 

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience


> To: hono-dev@xxxxxxxxxxx
> From: gsim@xxxxxxxxxx
> Date: Wed, 27 Apr 2016 15:26:56 +0100
> Subject: Re: [hono-dev] Redundant(?) properties in API messages

>
> 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

Back to the top