-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Close client connection on JWT expiry #106
Comments
If I understand correctly, you should be able to use the new You may also find the MOSQ_EVT_TICK event useful, it is called on every instance of the main event loop. |
Oh, I missed that! Thanks, @ralight, now it should be fairly easy to return a custom error from the plugin and kick out the client on |
Update: I already started a (local) branch on this to kickoff expired users, though I'm not sure about polling client statuses. Anyway, when I have the basis for kicking out on request, I'll open a PR and let you know so we can decide if that's enough or active polling is needed (I've given Mosquitto events a quick look, but am not entirely sure how they'll work with this package since I need to add some queryable mechanism to tell who/what is to be evicted, while also exposing that to C code. It's not that hard, I'm just not sure if it's worrh it). |
It's been a while since I started and then forgot about this, please ping me if there's still interest in getting it implemented. Cheers! |
Well, it's been a long while since my last comment asking for interest on this. There were some emoji reactions, but I don't get notified about those and might very well be as old as my response. So I'll give it a couple of days to see if there's any new comment, and hopefully a PR to review, or just close the issue. Not that I think it's an unworthy feature, I actually like the idea a lot, but if no one contributes then it's probably not gonna happen. Sorry about that. |
Hi @iegomez, really love to see this feature implemented. Otherwise, there will be a security hole there. |
@spencerfeng I won't be implementing it, but a PR is very welcome. |
This issue follows and summarises a discussion in #90 about handling of JWT expiry times.
Currently the mosquitto plugin interface does not provide a mechanism for us to feed back an expiry time for a user, either when the user is first queried or when the expiry time is reached. This means that our only means to enforce the expiry time is to stop sending subscribed data and refuse further subscribe or publish requests. This is slightly messy since from the client's point of view, its subscriptions remain active.
Since the mosquitto plugin interface is currently under review (see eclipse-mosquitto/mosquitto#1779) we should aim to keep a dialog open with the maintainers of that project to find a way to feed back this expiry time, then implement in this plugin.
The text was updated successfully, but these errors were encountered: