mosquitto-users team mailing list archive

[Remi SALEMBIER <remi.salembier@xxxxxxx>]

OK, I am going to open a ticket in Launchpad to be sure it will not be forgotten in the next release ;)

By the way, are you planning to launch this release before the MQTT interop testing day (17th March) ? ("we will have at least one Mosquitto instance available for anyone to test against on the day. We expect to have Mosquitto updated to allow OASIS conforming clients to connect")

Remi
-----Message d'origine-----
De : rogerlight@xxxxxxxxx [mailto:rogerlight@xxxxxxxxx] De la part de Roger Light
Envoyé : jeudi 5 décembre 2013 17:19
À : Remi SALEMBIER
Cc : mosquitto-users@xxxxxxxxxxxxxxxxxxx
Objet : Re: [Mosquitto-users] Mosquitto Plugin ACL check improvements

Hi Remi,

Yes, it should be in the next version as it is actually quite a straightforward change. The next version has been accumulating features to be implemented and so may become 2.0. This would match nicely with being the first Eclipse release, particularly if the MQTT-SN code from RSMB is merged.

Cheers,

Roger


On Thu, Dec 5, 2013 at 3:52 PM, Remi SALEMBIER <remi.salembier@xxxxxxx> wrote:
> Thanks for your answer Roger.
>
> I agree with you about the current ACL system which is able to control read and/or write access.
> But as you said, an explicit subscription control has also some advantages (wildcards control). It also allows to not have to verify for each subscriber if it has the read access for every publication (it will be blocked when subscribing).
>
> Have you got an idea if this feature could be present in the next major release (1.3) ?
>
> Thanks,
> Remi
> -----Message d'origine-----
> De : rogerlight@xxxxxxxxx [mailto:rogerlight@xxxxxxxxx] De la part de 
> Roger Light Envoyé : jeudi 5 décembre 2013 15:14 À : Remi SALEMBIER Cc 
> : mosquitto-users@xxxxxxxxxxxxxxxxxxx
> Objet : Re: [Mosquitto-users] Mosquitto Plugin ACL check improvements
>
> Hi Remi,
>
> The ACL check needs to be carried out on each publish because both subscriptions and ACLs can contain wildcards.
>
> If I had an ACL to allow read only access to the topic read/only , should I deny subscriptions to # for example?
>
> One thing I do have on my list of things to add is explicit subscription control, which is essentially what you are suggesting. I think it is most useful with wildcards - denying access to subscriptions to # would be useful in some situations for example.
> This is a separate issue to the current read/write ACLs though.
>
> Cheers,
>
> Roger
>
>
> On Thu, Dec 5, 2013 at 11:38 AM, Remi SALEMBIER <remi.salembier@xxxxxxx> wrote:
>> Hi,
>>
>>
>>
>> By playing with the Mosquitto plugin and the function 
>> mosquitto_auth_acl_check, I found curious that every single 
>> publication is verified from both part, the publisher and the 
>> subscriber. Wouldn’t it be nicer to be able to intercept “wrong”
>> subscriptions directly when the client tries to subscribe to a topic ?
>>
>> I suppose it would not be a lot of work, considering it would be 
>> possible to reuse the function mosquitto_acl_check using a third 
>> parameter pointing to a subscribe event (MOSQ_ACL_READ / 
>> MOSQ_ACL_WRITE / MOSQ_ACL_SUB ? ). The function would be called with this parameter in “mqtt3_handle_subscribe”
>> (read_handle_server.c) around line 500.
>>
>> I tried to send a pull request on bitbucket so you can have a look at 
>> my proposal, but it seems it is not possible to clone the repository 
>> at the moment (URL not valid).
>>
>>
>>
>> Regards,
>>
>> Remi
>>
>>
>> --
>> Mailing list: https://launchpad.net/~mosquitto-users
>> Post to     : mosquitto-users@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~mosquitto-users
>> More help   : https://help.launchpad.net/ListHelp
>>