Forcefully closing an MQTT client about mosca HOT 10 CLOSED

Also to note is that when a client times out, the binding isn't removed from the backend side (amqp in our case) whereas if the client disconnects itself it is removed. Is this by design?

from mosca.

Your problem is happening because your clients are being authorized, then they subscribe successfully and in the end the connection is closed.

I think there are two problems: firstly you should not call the close method inside the authenticate function, but you should call the callback with a false argument, like it's done in the built-in authenticate: https://github.com/mcollina/mosca/blob/master/lib/authorizer.js#L80-L82.

However, that behavior is definitely a bug and it even may be exploited in some way. The main reason is that in this lines the unsubAndClose method is not called: https://github.com/mcollina/mosca/blob/master/lib/client.js#L251-L258.

Actually, your second issue is the very same bug. Here the unsubAndClose method is not called: https://github.com/mcollina/mosca/blob/master/lib/client.js#L251-L258.
I think the unsubAndClose method should disappear and moved it inside close.

Could you please work a pull-request out of this? Please, also add a couple of unit tests.

from mosca.

"Your problem is happening because your clients are being authorized, then they subscribe successfully and in the end the connection is closed."

I think you misunderstood the scenario :-) I am disconnecting the OLD client (by looping through the list of currently connected clients and finding the one that has the same username) but I think the idea of where the issue lies is the same. I'll work on the fix tomorrow

from mosca.

Oh yes, definitely. However the problem is the very same.

Looping through all clients seems highly inefficient: you should definitely maintain a map of usernames and their client representation.

from mosca.

Any news on this side? Could you please try the new released version?

from mosca.

It include the SSL support!

from mosca.

Hi @mcollina, sorry it has been a busy week! Will look at getting onto this ASAP. Should I be moving all of the work that is done in unsubAndClose just into close? Will create a pull request when done

from mosca.

I've fixed a couple of problems on that.. give it a go in master and see. You can also have a look at #56.
I think the whole "close" situation is a total mess: there are three (!!) methods for closing called in different moments and the thing is not really tested.

As a start, you can remove the unsubAndClose method, but I'd like to have unit test for covering this functionality.

from mosca.

I think we should fix this soon, as we are not complaint with MQTT in this regard. The spec says:

If a client with the same Client ID is already connected to the server, the "older" client must be disconnected by the server before completing the CONNECT flow of the new client

from mosca.

Merged :-)

from mosca.