-
-
Notifications
You must be signed in to change notification settings - Fork 506
Client connection closed if publish is not authorized #596
Comments
@gotev I do not understand, the spec says to close the connection. |
From the specifics, it's said that if the publish is not authorized, the server must send a positive ack or close the connection. At the moment it's not possible to send a positive ack |
The positive ack is in the form of a PUBACK if QoS=1. It's sent automatically if the authorization succeed. |
I think he has the same question as me. Example. A user sends a message to a topic, if a certain condition is met by the business logic the message passes (the message complies with an internal protocol for example, or bandwidth limitation). I tried doing this with with server.published and server.authorizePublish authorize closes the connection and thats ok. |
no. there is no way the error can reach the client, it's the MQTT protocol. |
Ok, ill do it then by publishing a message back to the client on a topic with an error message. |
My question now is. |
@RobertoBiundo no. |
Is there any way to skip the queue and send the message using the socket directly and then close the connection? |
Since this works over TCP/IP the message should arrive to the client. I know that i have to modify the broker to achieve this. But do you think is posible in an easy way? |
Mosca does not have that capability, but Aedes do https://github.com/mcollina/aedes. See https://github.com/mcollina/aedes#clientpublishmessage-callback. |
Ahhh!, nice!...nice.... Thank you very much ! |
Scenario
A client authenticates with Mosca server (2.2.0) and then tries to publish a message on a topic on which it does not have access. The publish does not succeed and the client connection is closed by the server.
By reading the MQTT specification I've seen this:
By digging in the Mosca code I've seen that the client connection gets closed if the authorization is not granted and there's not a way to return an ack without actually performing the publishing of the message. I think it will be useful to have the possibility to not disconnect the client if a publish fails due to authorization. Simply return a puback without publishing the message.
The text was updated successfully, but these errors were encountered: