There are a couple of ways you can do that:
- use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
- use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745
El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:There are a couple of ways you can do that:
- use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
- use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745
A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.
I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
Il giorno martedì 21 febbraio 2017 11:38:18 UTC+1, Ancor Gonzalez Sosa ha scritto:
El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:There are a couple of ways you can do that:
- use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
- use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745
A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.I don't see this as overkill, especially considering it can be done without infrastructure I believe.
I don't see how notifying the participant about anyone that subscribes to him is going to help either (if not to potentially add a lot more verbosity to the events, especially if publishers have a lot of viewers), as subscribers can be created without any context at all and so you wouldn't identify lurkers anyway.
Any of the two mechanisms above would prevent that, as the former would prevent the creation of the handle, and the latter the ability to publish/subscribe: any other approach would only attempt to fix things after they already happened.
I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
As explained above, I don't like the idea of spamming the publisher with info on any new viewer that joins. We have scenarios with hundreds of viewers and this would be useless traffic, besides the fact that, since subscribers potentially don't have any context, this cannot be used to avoid lurkering. The private_id property allows for some context, but that's meant to stay private between user and server, and making it available to other participants is a bad idea.
Sorry, Gmail fooled me and I sent this only to Lorenzo. Re-replying to the list.
El martes, 21 de febrero de 2017, 11:48:44 (UTC+1), Lorenzo Miniero escribió:Il giorno martedì 21 febbraio 2017 11:38:18 UTC+1, Ancor Gonzalez Sosa ha scritto:
El martes, 21 de febrero de 2017, 11:07:17 (UTC+1), Lorenzo Miniero escribió:There are a couple of ways you can do that:
- use something like the auth tokens: users need to go through something of yours first, which results in a token being added to the Admin API that they can then use to talk to Janus; https://janus.conf.meetecho.com/docs/auth
- use the recently added ACL support in the VideoRoom (and a couple others) plugin: again, users need to go through something of yours first, which results in an identifier being added to the room's ACL, and this identifier needs to be presented by users who want to join/subscribe: https://github.com/meetecho/janus-gateway/pull/745
A little bit overkill, IMHO. One of the things I like about Jangouts is that, server-side, it only depends on Janus. Adding another component to the infrastructure or going for a full-featured authentication system is not exactly what I wanted.I don't see this as overkill, especially considering it can be done without infrastructure I believe.Then I misunderstood something. As I see both 1 and 2, I need something to keep the list of "authorized" participants in a room and to generate one token for each participant (and delete the token when the user exits the room). That "something" would not be Janus itself and it would not be javascript code running in the client (browser), so I need some infrastructure. Something running anywhere so the javascript client can:- ask for a token so it can join- delete a token on exit- ask, at least, how many tokens are active, so I can verify the status is correct.Isn't it? Or maybe I'm just misunderstanding how you suggest to use those features.Take into account I don't want to implement real authentication (which is a quite complex topic and would open a can of worms). I just want to make sure the users have a clear view of the situation of the room (i.e. the real number of publishers/subscribers).
At most (not really a requisite), I would enforce symmetric use (you cannot subscribe unless you publish). But that is already one step too far... which means authentication is two steps too far :-)
I don't see how notifying the participant about anyone that subscribes to him is going to help either (if not to potentially add a lot more verbosity to the events, especially if publishers have a lot of viewers), as subscribers can be created without any context at all and so you wouldn't identify lurkers anyway.
But you will know they are there, which is my only goal so far.
Any of the two mechanisms above would prevent that, as the former would prevent the creation of the handle, and the latter the ability to publish/subscribe: any other approach would only attempt to fix things after they already happened.
I know, I wanted to alert the users about the situation, not necessarily prevent it from happening. At least, not at the cost of having to design a secure mechanism for (pseudo)authentication.
I have identified 8 places in the videoroom plugin where the list of subscribers of a participant is altered. I will try to create a PR that sends a message to the publisher in all those 8 cases. Any reason you foresee for it to not work?
As explained above, I don't like the idea of spamming the publisher with info on any new viewer that joins. We have scenarios with hundreds of viewers and this would be useless traffic, besides the fact that, since subscribers potentially don't have any context, this cannot be used to avoid lurkering. The private_id property allows for some context, but that's meant to stay private between user and server, and making it available to other participants is a bad idea.
I see. Just a question about this. Would those "lurkers" who have provided minimal context be displayed by the listparticipants command?
[...]