Adding users into BigBlueButton through API
Josh
Is it possible to add multiple users to a single room through the
API?
Thanks so much
Fred Dixon
Yes, you make one API call for each user. See
http://code.google.com/p/bigbluebutton/wiki/API
Let us know if the documentation was unclear.
Regards,... Fred
> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
>
Josh
user and moderator per room? like its mentioned below...???
Create meeting example:
http://yourserver.com/bigbluebutton/api/create?name=Test+Meeting&meetingID=abcdef&attendeePW=111222&moderatorPW=333444
How can I create user1 password1,user2 password2,user3 password3?
Thank you Fred!
Fred Dixon
Users must login through a front-end 3rd party application that, in
turn, creates the room. This front-end application could be Moodle,
Sakai, Wordpress, Joomla, or one of our API examples. Regardless of
the application, they all use the same 'create' and 'join'
BigBlueButton API calls.
Typically, when creating a room, the application dynamically creates a
moderator and viewer password, then calls 'create'. Each password is
a sixteen character string, for example, that exists only during the
life of the room.
Now you want a user to enter the room. First, the user must login to
the application. For example, in Moodle, a user logs in through the
Moodle user authentication using their own username/password. Once
logged in, Moodle knows if they are a student or non-student. From
within Moodle, when a user joins a BigBlueButton room, the
BigBlueButton activity module calls 'join' to create a URL using
either the 16 character moderator or 16 character viewer password.
When that join URL hits the BigBlueButton server (returned back from
Moodle when clicking a link to join a room), BigBlueButton will verify
the request (check the checksum and password) and log the user in with
the corresponding permissions.
The key point in the above scenario is the user never sees that
password. It's just used by the front-end application to create the
appropriate join URL.
In this way, there is no user database in BigBlueButton, nor is there
any password database. Once the meeting ends, all knowledge of the
users who joined and the password (moderator or view) is gone. The
front-end application can log in multiple users as moderators or
viewers.
In other words, your application, using the BigBlueButton API,
controls the logins (such as with the Moodle user database), and it
decided when to return a URL to return back to the user, and it
decides what password to use when creating that join URL.
Regards,... Fred
Hedge Hog
I think this is made much clearer if we don't refer to the 16
characters as a password - that immediately invokes the connotation
that the viewer and moderator know them.
Better, would be to use the terms:
<room>-view-token
<room>-moderate-token
Alternatively, (I haven't checked the implementation) if they are a
public key that is being handed to the server:
<room>-view-public-key
<room>-moderate-public-key
Note that in both cases the use of verb rather than noun indicates
they are activity rather than user oriented.
But overall I think the use of the term password is misleading here,
because that would usually means
'this-is-something-you-will-need-to-know'
HTH
--
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
Josh
Maybe we could add a line to the documentation that users should be
managed by an external application and bbb doesn't manage them.
@HTH,i think we could additionally add a line like like the above.
Regards
On Mar 25, 1:56 am, Hedge Hog <hedgehogshia...@gmail.com> wrote: