The CONNECT and SUBSCRIBE are two different command messages. The subscription phase comes after the connection.
Also the other fact is a single connection could involve multiple topic subscriptions. So lets say if a given tenant sends a list of topic subscriptions there could be subscriptions which the tenant could be authorised among that list. So closing/refusing the entire connection might not be appropriate in this case. - 0x05 (Connection Refused: not authorized) is sent as an acknowledgement for CONNECT message (CONNACK). i.e a given client has provided unauthorised credentials etc. During this phase the subscription will not occur, we only could validate whether a given tenants credentials are correct or not. - When the subscription happens based on my understanding of the spec it has passed the CONNACK stage. The only way we could indicate an error related to subscription is through SUBACK. # The MQTT 3.1 specification has a limitation where error codes cannot be sent with SUBACK. Hence for 3.1 spec having subscription failed in silent mode is expected behaviour. You could find a similar discussion on [1]. Based on [1] what they've done is hacked the client and the server to accept error codes for 3.1 specification. This will not be clean and will not interop with other clients (even if we could hack the server to send error codes, the clients which has implemented according to 3.1 specification will not accept the error message). Another option is to initiate a disconnection from the broker to avoid stale connections. But then again as mentioned in the beginning if there're list of subscriptions for a connection, even the authorised subscriptions would not be able to consume. # The MQTT 3.1.1 specification there's an error code introduced 0x80 for forbidden subscriptions. So that should be the way we should ideally use for indication of an error IMHO. But it'll be available in 3.1.1. [1] https://issues.jboss.org/browse/ENTMQ-990 On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya <[email protected]> wrote: > Hi, > > Yes, Connection Refused, not authorized is the best we can do. > > @Pamod, any batter alternative? > > Thanks! > > On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake <[email protected]> > wrote: > >> Hi Pumudu, >> >> MQTT spec doesn't talk about a permission model, So IMO the closest error >> we can propagate to the client is "0x05 Connection Refused, not authorized". >> >> >> With Regards, >> >> On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage <[email protected]> wrote: >> >>> Hi All, >>> >>> If a tenant don't have permission to subscribe to a given topic (tenant ' >>> a.com' try to subscribe to tenant 'b.com') currently it will keep >>> connected even though it's not subscribed, because user authentication was >>> successful. This is misleading to subscriber as no return code sent and >>> it's actively connected to broker. >>> AFAIK mqtt don't define how to handle tenancy scenarios in it's spec. >>> Couldn't find a definition in MQTT spec 3.1.0/3.1.1 on how to reject if >>> permission denied to subscribe to a given topic(due to tenancy). >>> >>> One option to handle this scenario is to send return code 5 (Connection >>> Refused, not authorized) to client if it doesn't have permission to >>> subscribe to given topic. This way client will disconnect if it don't have >>> permission to subscribe. Is this acceptable or are there any alternatives >>> to handle this scenario? >>> >>> jira https://wso2.org/jira/browse/MB-1409 >>> >>> Thanks, >>> Pumudu >>> -- >>> Pumudu Ruhunage >>> Associate Software Engineer | WSO2 Inc >>> M: +94 779 664493 | http://wso2.com >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Yasassri Ratnayake >> Software Engineer - QA >> WSO2 Inc ; http://wso2.com >> lean.enterprise.middleware >> *Mobile : +94715933168 <%2B94715933168>* >> *Blogs : http://yasassriratnayake.blogspot.com >> <http://yasassriratnayake.blogspot.com/>* >> * http://wso2logs.blogspot.com <http://wso2logs.blogspot.com>* >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Hasitha Abeykoon* > Senior Software Engineer; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- *Pamod Sylvester * *WSO2 Inc.; http://wso2.com <http://wso2.com>* cell: +94 77 7779495
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
