-
Notifications
You must be signed in to change notification settings - Fork 39
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
Add optional room_ids to JWT #81
Conversation
The changes looks good. We need to make sure that old tokens without room_ids still works. |
While you're at it :-) you may move all the join validation logic into a function so we can also call it in |
@mqp I'll start testing this next week. I just finished adding to my app the room security logic by organization, only members of an organization can access a room. The backend and ui works great, but without the JWT for janus, just knowing the room id, you can eavesdrop the conversations without the others in the rooms knowing you're there. :D |
@mqp This works great! I use a simple Phoenix backend with phx_gen_auth and absinthe, I added guardian to generate the jwt and return it as part of my graphql query when getting the room info. I'll document how to configure the key in both phoenix and janus to generate the jwt and how to set it with setJoinToken later. I tested without room_ids
and with room_ids
In my js code, I do the graphql query and set the results in
I tested to hijack the room like this:
Without token:
With token with room_ids from another room:
With token without room_ids
With expired token:
For
If we want to fix it, we need to change the api of the subscribe message to include room_id and token. We may revisit this as part of #76 So you can merge this PR. And you may want to comment Line 609 in a2fffd1
MessageKind::Subscribe and janus-plugin-sfu/src/messages.rs Line 74 in a2fffd1
process_subscribe function for extra security until we change the API.
|
See my notes if you want to implement the JWT creation in a Phoenix app #77 (comment) |
OK, I'll merge this. The subscription is a good point. Since the NAF Janus adapter doesn't use subscribe, I'm not afraid to make breaking changes to it. I think it should take a user ID, a JWT, and no room ID, and check to see whether the user is in any room authorized by the JWT; if so, you're allowed to subscribe to them. If this sounds good I'll probably code it up next evening. |
I disagree. If you do like you said, it's almost like the join message with the subscribe param, so not worth to have a different api to do the same thing. |
If we have the concept of being in the room without being a publisher, your proposal makes sense. But we don't have that currently. |
I did a fix in naf-janus-adapter that wrongly did a delayed reconnect in case of error in join message. |
Maybe I miscommunicated:
I mean that the user ID is the ID of the person you want to subscribe to. So even if you have no publisher and have not joined any room, you could subscribe to a publisher who has joined some room, as long as you have a JWT with that room in its |
Ahhhhhh :D I misunderstood it indeed. I understand it a lot better now. This is a great solution, I agree ;-) |
I updated #83 with my understanding. |
Yeah, that's what I'm suggesting. |
Implements #78. Now if JWT authorization is enabled, you may join a room only if you send a JWT containing
join_hub = true
and with either noroom_ids
(i.e. like all old tokens; you can join any room) or aroom_ids
array containing the room ID you're trying to join.Not yet tested, so not merging yet.