Request for Feedback: API changes to BigBlueButton 0.8
Fred Dixon
0.8. These changes are to support the upcoming record and playback
functionality in BigBlueButton 0.8 and to improve the security of
joining a session.
We've tried to keep the changes minimal while at the same time
expanding the API to support record and playback.
We welcome all your feedback on the changes below.
** Overview
In the current API, BigBlueButton supports the following calls:
create
join
end
isMeetingRunning
getMeetings
getMeetingInfo
In BigBlueButton 0.8 there will be updates to the create, join, and
getMeetings, and getMeetingInfo API calls, along with the addition of
three new API calls to support record and playback:
getRecordings
setRecordingsPublish
deleteRecordings
The current API version is 0.7 (this is the result returned from a
BigBlueButton 0.71a server). This string will change to 0.8 so you
can detect the newer version of the API on the BigBlueButton server.
All the API changes and additions are backward compatible.
Applications using API version 0.7 calls will work unchanged on a
BigBlueButton 0.8 server.
** Updates to existing API calls
1. Add the optional parameters ‘record’ and ‘duration’ to create
record
type: string
values: true|false
default: false
duration
type: integer (in minutes)
default: 0 (no automatic end)
Setting ‘record=true’ instructs the BigBlueButton server to record the
media and events in the session for later playback. BigBlueButton
starts recording when the first person joins the session, and stops
recording when either the last person leaves or upon receiving an end
API request for the associated meetingID.
When the recording stops, BigBlueButton automatically begins
processing the recorded media and events using one or more ‘ingest and
processing’ scripts installed on the BigBlueButton server. The
default scripts will playback the slides and audio in the session.
Meetings now have a duration. The default is 0, which means the
meeting continues until the last person leaves or an end API calls is
made with the associated meetingID. This is how meetings work in
BigBlueButton 0.7.
However, when recording a meeting, you should pass a value for
‘duration’. When the length of the meeting reaches the duration,
BigBlueButton automatically ends the meeting. Passing a duration for
a meeting prevents the scenario where one (or more) users linger in
the session long after the meeting has finished (i.e. leave their
browser open over night), indefinitely delaying the processing of the
recording for the meeting.
2. The ‘meetingID’ parameter for create should not contain commas
If you intend to use the new getRecordings, setRecordingsPublish, and
deleteRecordings API calls, the value for ‘meetingID’ must not contain
commas.
The above new API calls will accept a set meetingIDs, separated by a commas.
2. create will accept one (or more) additional parameters prefixed
with ‘meta_’
meta_* (optional)
type: string
These additional metadata parameters will be stored by BigBlueButton
and later retrievable via the getMeetingInfo call (while the meeting
is running) and getRecordings (after the meeting is finished and the
recording is ready for access).
Examples of meta parameters are meta_Presenter, meta_category,
meta_LABEL, etc. All parameters are converted to lower case, so
meta_Presenter would be the same as meta_PRESENTER.
3. The parameters ‘name’ and ‘meetingID’ can now differ in create.
The ‘meetingID’ parameter should be an internal key value (without
commas) created by the 3rd party application calling the API. In
contrast, the ‘name’ parameter is meant as an external, user visible
value accesible via the %%CONFNAME%% string in the welcome message.
The parameters ‘name’ and ‘meetingID’ can now differ, enabling 3rd
party applications to change the ‘name’ between sessions, such as
“First Meeting”, “Second Meeting”, while keeping a consistent
‘meetingID’ for later retrieval of recordings.
4. The XML result from create now includes ‘createTime’.
Reason: Third-party applications using the BigBlueButton API can now
pass ‘createTime’ a join URL to prevent re-use of the URLs between
sessions with the same ‘meetingID’ (see 6).
The value for ‘createTime’ is the unix epoch time (see
http://en.wikipedia.org/wiki/Unix_time).
Here’s a sample return from the create
<response>
<returncode>SUCCESS</returncode>
<meeting>
<meetingID>87sdf89210gt</meetingID>
<createTime>1308591802</createTime>
<attendeePW>testa</attendeePW>
<moderatorPW>testm</moderatorPW>
<hasBeenForciblyEnded>false</hasBeenForciblyEnded>
<messageKey>createSuccess</messageKey>
<message>Meeting has been create</message>
</meeting>
</response>
5. getMeetings and getMeetingInfo also return ‘createTime’, along
with the value for ‘record’, and ‘duration’
For example, here is a sample XML response from getMeetingInfo
<response>
<returncode>SUCCESS</returncode>
<meetingID>123456</meetingID>
<createTime>1308591802</createTime>
<attendeePW>abc</attendeePW>
<moderatorPW>qwe</moderatorPW>
<running>true</running>
<startTime>Thu Mar 04 14:05:56 UTC 2010</startTime>
<endTime>null</endTime>
<participantCount>2</participantCount>
<moderatorCount>1</moderatorCount>
<attendees>
<attendee>
<userID>40</userID>
<fullName>JT Attendee</fullName>
<role>VIEWER</role>
</attendee>
<attendee>
<userID>37</userID>
<fullName>JT Moderator</fullName>
<role>MODERATOR</role>
</attendee>
</attendees>
<messageKey/>
<message/>
</response>
Note: ‘createTime’ is the time the meeting was create by
BigBlueButton, ‘startTime’ is when the first person joins, and
‘endTime’ is the time when last person has left the meeting or when
BigBlueButton received an end API call for the meeting.
6. join can now pass ‘createTime’ parameter
createTime (optional)
type: integer
When passing ‘createTime’ with a join URL, BigBlueButton will ensure
it matches the ‘createTime’ for the session. If they differ,
BigBlueButton will not proceed with the join request.
This prevents a user from reusing their join URL for a subsequent
session with the same ‘meetingID’.
While the ‘createTime’ parameter is optional, we recommend that 3rd
party applications using the BigBlueButton API add this parameter to
their join calls.
** New API Calls
7. Add ‘getRecordings’ API call
meetingID[,meetingID]* (optional)
type: string
checksum
type: string
Retrieves the recordings that are available for playback for a given
‘meetingID’ (or set of meeting IDs).
Each ‘meetingID’ can have multiple recordings. Each recording
(returned in the XML described below) has a ‘recordID’, which is
computed as ‘meetingID’-’createTime’.
Each ‘recordID’ can have multiple playback formats. For BigBlueButton
0.8, the built-in playback format, called simple, will playback slides
+ audio. By adding your own ingest and processing scripts you can add
additional playback formats to BigBlueButton 0.8.
There will be a time lag between the end of a meeting and the
availability of one (or more) playback formats. This time lag depends
on how long a given ingest and processing script takes to process the
raw media and XML events recorded by BigBlueButton into a format for
playback.
For each type of playback format, BigBlueButton returns a url and
length. An example is
<format>
<type>simple</type>
<url>http://server.com/simple/playback?recordID=183f0bf3a0982a127bdb8161-1308597520</url>
<length>62</length>
</format>
There are three different usages for getRecordings
getRecordings?checksum=2134132421342134
The getRecordings API call will return a list of all recordings on the
BigBlueButton server that are available for playback.
getRecordings?meetingID=CS101&checksum=457897ew56654
If the optional parameter meetingID is passed then BigBlueButton will
return all the recordings for the given meetingID that are available
for playback.
getRecordings?meetingID=CS101%2CCS102&checksum=457897ew56654
BigBlueButton will return all the recordings that are available for
playback for a set of meetingIDs. Note, the string must URL encoded
(UTF-8).
The information returned from getRecordings includes any meta_*
parameters initially passed using the create call.
Examples of response:
No Recordings
<response>
<returncode>SUCCESS</returncode>
<messageKey>noRecordings</messageKey>
<message>No recordings available</message>
</response>
Get Recordings
<response>
<returncode>SUCCESS</returncode>
<recordings>
<recording>
<recordID>183f0bf3a0982a127bdb8161-1308597520</recordID>
<meetingID>CS101</meetingID>
<name><![CDATA[On-line session for CS 101]]></name>
<published>false</published>
<startTime>Thu Mar 04 14:05:56 UTC 2010</startTime>
<endTime>Thu Mar 04 15:01:01 UTC 2010</endTime>
<metadata>
<title><![CDATA[Test Recording]]></title>
<subject><![CDATA[English 232 session]]></subject>
<description><![CDATA[First Class]]></description>
<creator><![CDATA[Fred Dixon]]></creator>
<contributor><![CDATA[Richard Alam]]></contributor>
<language><![CDATA[en_US]]></language>
</metadata>
<playback>
<format>
<type>simple</type>
<url>http://server.com/simple/playback?recordID=183f0bf3a0982a127bdb8161-1308597520</url>
<length>62</length>
</format>
</playback>
</recording>
<recording>
<recordID>183f0bf3a0982a127bdb8161-13085974450</recordID>
<meetingID>CS102</meetingID>
...
</recording>
</recordings>
<messageKey/>
<message/>
</response>
8. Add ‘setRecordingsPublish’ API call
Set the <publish>..</publish> value to true or false in the
getRecordings result for one (or more) recordings.
You can also pass a set of recordIDs by separating them by commas.
recordID[,recordID]*
type: string
checksum
type: string
IC – Incorrect Checksum
<response>
<returncode>FAILED</returncode>
<message_key>checksumError</messageKey>
<message>You did not pass the checksum security check</message>
</response>
DNE – Does Not Exist
<response>
<returncode>FAILED</returncode>
<message_key>notFound</messageKey>
<message>We could not find a recording with that recordID</message>
</response>
Publish
<response>
<returncode>SUCCESS</returncode>
<published>true</published>
</response>
9. deleteRecording
Delete one (or more) recordings from the BigBlueButton server. You
can also pass a set of recordIDs by separating them by commas.
recordID[,recordID]*
type: string
checksum
type: string
DNE – Does Not Exist
<response>
<returncode>FAILED</returncode>
<message_key>notFound</messageKey>
<message>We could not find a recording with that recordID</message>
</response>
Success
<response>
<returncode>SUCCESS</returncode>
<deleted>true</deleted>
</response>
** Summary
Lots of details above. Again, we tried to keep the additions to the
API as minimal as possible while enabling flexibility for creating,
accessing, and managing the recordings in BigBlueButton 0.8.
We welcome your feedback.
Regards,... Fred
Temuujin Khenmedekh
Hi thanks for all your hard work guys. So when is the release date for this ?
> --
> 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.
>
Fred Dixon
We release on quality, not dates.
However, you can tell when an iteration is getting close to a release
when it enters beta. We still a few weeks (not months!) away from a
beta. Our beta cycles are historically four to six weeks long, but
they will be as long (or as short) as needed to ensure we have a
quality release.
Our last release was BigblueButton 0.71, released on January 13, 2011.
This has been a long development cycle for us, and we're looking
forward to getting to beta.
Regards,... Fred
cforce
Juts to be sure. Can i prevent users to join with a invite url several times, or can i prevent to only join the meeting once?
Please provide more information, i don't really understand what this time param does.
Fred Dixon
With a bit more thought ... BigBlueButton could reject the join URL if
a user with the same userID is already in the meeting. If you have
two accounts on your server with the name 'cforce', but they both have
different IDs in your system, both could still join.
Since the userID parameter is optional, a 3rd party application could
omit the userID and essentially disable such a check.
Regards,... Fred
> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/bigbluebutton-dev/-/SqShKHeL4T4J.
Fabi
Fred Dixon
> How can i bind a userid with a username and and attende passwort.
> Till now there is one url for all attendes with the same passwort and the
> same base url.
Just to be clear, BigBlueButton does not have a user/password
database. Validation of the user is the responsibility of the 3rd
party application. Once validated, the 3rd party application creates
for the user a join URL and returns it to the user's browser. The
user is then logged into BigBlueButton.
Assuming for the moment you are a developer and are integrating
BigBlueButton into your application, then the invite URLs you send out
could point to your application, not directly to BigBlueButton. When
a user clicks on the invite URL, they are redirected to your
application first, at which point you can validate them first before
returning back the final join URL for BigBlueButton.
For example, the API example for creating a meeting at
http://demo.bigbluebutton.org/bigbluebutton/demo/create.jsp
create an invite URL that, when clicked, asks the user for their name.
The logic of create.jsp could be extended (or integrated into another
application) to also ask them for a password as well.
If BigBlueButton 0.8 enforces a unique userIDs in a session, then if
two people use the same joinURL, once one of them joins the session,
BigBlueButton would prevent the other from joining.
Regards,... Fred
Leonardo Daronco
Very nice and detailed email.
I got some comments and questions about the API.
1)
The recordings will be retrieved using the "meetingID". Currently, our web app generates a random "meetingID" whenever a meeting is created. We do that to prevent the re-use of the join URL and to avoid problems when "end" is called (see below).
With the new "createTime" param I think the re-use of join URLs is solved. And we can also use the "userID" for this purpose.
But the issue with "end" will still exist. Whenever you call "end" the target "meetingID" will be invalid until this meeting is removed from memory. So the user will not be able to join his meeting again unless we change the "meetingID".
So, if we change the "meetingID" as we're doing today it will be harder to retrieve all recordings for a specific meeting (or for a "room", where several meetings can happen). But if we don't change it we have that issue with the "end" calls.
Why is it not possible to call "create" using the same "meetingID" of a meeting that "hasBeenForciblyEnded"?
The docs point to issue 394 (http://code.google.com/p/bigbluebutton/issues/detail?id=394) and state that "Now, after calling "end" to forcibly end a meeting, you are not allowed to join that meeting again". Isn't this the same join URL re-use issue that "createTime" and "userID" can solve now?
2)
This is related to the previous question. Let's say I do the following:
* Create a meeting at "createTime" = 1000
* I join this meeting
* I leave the meeting (I didn't call "end", I just left)
* I wait some time and then create this meeting again (same "meetingID") at "createTime" = 5000
Now if I call "getMeetingInfo" for this meeting the "createTime" will be 1000, right?
Wouldn't be better if it was updated to 5000?
I mean that whenever I call "create" I want to start the meeting again. If it's already running, that's ok, I will get an error. But if it is *not* running, maybe it could be created again (or just updated using the parameters passed to "create").
3)
Some parameters passed to "create" are not returned by "getMeetingInfo". They are:
* welcome
* dialNumber
* voiceBridge
* logoutURL
* name
This is not a major problem, but I think it would be nice to be able to fetch from BigBlueButton all the parameters used to create a room.
If my app created the meeting I will have access to these parameters. But if some other app created a meeting in the server I use (I guess this is not recommended, but it's possible :-) ), I will not have access to all of it's parameters. The "voiceBridge" might be the most important one in this case, to prevent duplicated values.
4)
With a bit more thought ... BigBlueButton could reject the join URL if
a user with the same userID is already in the meeting. If you have
two accounts on your server with the name 'cforce', but they both have
different IDs in your system, both could still join.
5)
Will the "maxParticipants" parameter for "create" work in 0.8? Or maybe will it be removed?
That's all for now. Thanks in advance!
Regards,
Leonardo Crauss Daronco
Cameron Banta
To improve security, I think that all of the API calls should take an optional current date and time parameter (a unix timestamp or iso8601 date and time, or whatever). If the current time is present, the server will check to see that it is within some amount (probably a minute or two) of the current time - and reject the api call if not. If the current time parameter is not present, the call will just succeed (for backward compatibility so as not to break things).
This allows the end user (developer) using the API to decide if they want the extra security of a constantly changing parameter. This with the salt/checksum will help prevent a url from being reused. Of course it can still be reused within that small time window.
-Cameron
Fred Dixon
Good suggestion.
However, one problem with this approach is the synchronization of
server times. If the caller's server clock is more than two minutes
out of sync with the BigBlueButton's server clock, for example, then
the API calls that requires a timestamp within one minute of the
server's timestamp will always be rejected.
To assist in synchronization, one approach could be to return the
BigBlueButton server's timestamp with the /bigbluebutton/api call,
such as having the call
http://demo.bigbluebutton.org/bigbluebutton/api
return
<response>
<returncode>SUCCESS</returncode>
<version>0.7</version>
<timestamp>3245323344</timestamp>
</response>
This would allow the caller to get an accurate timestamp from the
BigBlueButton server for the next API call (or for calculating
subsequent API calls) so that the timestamp passed in would be within
the acceptance window.
We need to study this more ... we're not security experts, and we need
to spend some time researching how other protocols (such as OAuth)
make their APIs secure.
Regards,... Fred
--
http://code.google.com/p/bigbluebutton/wiki/FAQ#BigBlueButton_Committer
> > <mailto:fabismai...@googlemail.com>> wrote:
> > > > How can i bind a userid with a username and and attende passwort.
> > > > Till now there is one url for all attendes with the same passwort
> > and the
> > > > same base url.
> > > > How can i use the new feature to send out join urls, which can't
> > be copied
> > > > (means reuse the same url in paralell) and make it impossible or
> > at least
> > > > difficlut tu guess join urls?
>
> > > >> > bigbluebutton-...@googlegroups.com
> > > >> >http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > > >> --
> > > >> 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
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> > > >>http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > > > --
> > > > 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
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> > > >http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > > --
> > > 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
> > <mailto:bigbluebutton-dev%2Bunsu...@googlegroups.com>.
> >http://groups.google.com/group/bigbluebutton-dev?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "BigBlueButton-dev" group.
> > To post to this group, send email to
>
>
> read more »
Ruediger Kannengiesser
my name is Ruediger from Germany. I am a new member in the BBB - Fan Club.
We are in the realization phase of a huge e-Learning and e-Conferencing environment, using
Drupal
Moodle
BBB
The Target is to build up a professional environment for students, professors and conference members with a number of participants that our system is able to handle. We decided for BBB because we´ve had the best feeling for the tool. But what we couldn´t figure out were data for the biggest BBB - installation.
The following parameters we couldn´t check:
biggest installation with BBB
- numbers of user
- bandwith
- server - power
- quality of video
- quality of audio
- both together
We are planning a really huge environment, even to build up a real alternate to the professional e-Conferencing systems.
It would be great to get some informations ore information sources. Greatings from Germany, Ruediger.
p.s. I am not the technician. I am the General manager of the company, just founded. So please do not lough if I ask "stupid" questions.
Rüdiger Kannengießer
> Subject: [bigbluebutton-dev] Re: Request for Feedback: API changes to BigBlueButton 0.8
> From: ffd...@gmail.com
> To: bigblueb...@googlegroups.com
> To unsubscribe from this group, send email to bigbluebutton-...@googlegroups.com.
Fred Dixon
We didn't know we had a BigBlueButton Fan Club :-).
First off, check out our FAQ on maximum number of simultaneous users
This FAQ entry gives you some suggestions in how to stress test your server.
For bandwidth usage, see
and recommended server
and video quality
The audio quality will improve in BigBlueButton 0.8 as we move to
wideband speex. The increased audio quality will require the
BigBlueButton server (specifically FreeSWITCH) to work harder to
transcode audio. See
http://groups.google.com/group/bigbluebutton-dev/browse_thread/thread/a36d61df9b9fc45b#
Finally, there is no formula for calculating # of users given the
number of variables. Your best approach is to your server and its
bandwidth with a number of users that reflect typical usage (you can
simulate large number of users by having ten friends each start a
BigBlueButton session in a browser tab) to determine the maximum load.
There are lots of items ahead on our roadmap, see
http://code.google.com/p/bigbluebutton/wiki/RoadMap1dot0
At the moment, the core development team is focused on making sure the
experience of using BigBlueButton for 25 users or less in a session
works really, really well. There is more work to be done, and the
shift to scaling BigBlueButton to large number of users will follow
it.
Regards,... Fred
--
http://code.google.com/p/bigbluebutton/wiki/FAQ#BigBlueButton_Committer
Fred Dixon
Thanks for your feedback! Here's our response below.
1)
When an ‘end’ API call is received, the API controller (bbb-web)
messages red5 (bbb-apps) to eject all the users. When users leave the
session, they call the API controller (bbb-web) to get the logouURL
associated with the meeting.
We’ve experimented with instantly purging the meeting from the API
controller (so you could immediately call ‘create’ with the same
meetingID), but there is a race condition where clients logout and the
API controller no longer has the meeting, and it throws an exception
when requested for a non-existent meetingID.
We agree that when you call 'end', the meeting is over, and you should
be able to call 'create' immediately afterwards. We'll look at
modifying it during the beta testing to match that behavior (no
promises!). We'll track the effort in this issue
http://code.google.com/p/bigbluebutton/issues/detail?id=980
Here's a bit more infor on how it works now.
In BigBlueButton there is a background process that runs every minute
to remove meetings that have finished (no users are present) or have
been ended. The background process determines if either of these
conditions *and* at least the number of minutes in
defaultMeetingExpireDuration has passed, which is defined in
/var/lib/tomcat6/webapps/bigbluebutton/WEB-INF/classes/
bigbluebutton.properties
and is default to 1 minute
# The number of minutes before the system removes the meeting from
memory.
defaultMeetingExpireDuration=1
This means there will be at least one minute (maximum of 2) between
the call of the ‘end’ to where the meeting is deleted from memory and
you can call ‘create’ using the same meetingID.
(2)
Once the meeting has been deleted from memory (as described above),
you have a clean slate. Calling ‘create’ will set a new createTime
for the meeting.
(3)
We don't have any specific design behind returning only a portion of
the parameters, other than it's an optimization and it 'encourages'
3rd party applications to maintain state.
Some developers initialy think that BigBlueButton has a database that
it maintains a record of all current and future meetings. It
doesn't. Meetings are only in memory and only last until they are
deleted or the software/server reboots.
The 3rd party application should assume the BigBlueButton server may
reboot at anytime (by an administrator, software error, power cycle,
etc.) and if the 3d party application has all this information on a
meeting, it can recreate the meeting anew after reboot.
At the moment, we're likely to leave it as is and just focus on fixing
bugs for the upcoming beta test.
(4)
Good suggestion, but after some thought implementation, but
restricting 'join' URLs to contain unique userIDs would need to be
done as a parameter to bigbluebutton.properties. If we added this
capability into BigBlueButton 0.8 as default, it will likely break
some existing integrations.
We've added an enhancement request for this at
http://code.google.com/p/bigbluebutton/issues/detail?id=981
Will look at doing this in a future iteration. Again, we're pretty
focused on finishing BigBlueButton 0.8 for beta testing/release.
(5)
We're not planning on implementating maxParticipants.
There are two constraints as play here. The
first is you create a meeting, it’s parameters are fixed. You can’t
change the moderator password half way through the meeting. The
second is we want to minimize the business logic in the BigBlueButton
server.
Here’s the example for not putting maxParticipants in BigBlueButton.
Let’s
say you create a meeting with 10 users, and half way through, you want
to have 11. If the BigBlueButton server enforced maxParticipants, you
can’t (you can't change the parameters after create).
But if the calling application enforced the maxParticipants (such as
querying the meeting before returning a join URL to ensure the meeting
didn’t exceed its max number of participants), then the calling
application
could dynamically change the maximum number whenever it wants.
Thanks again Leonardo for your feedback!
On Jul 27, 9:33 pm, Leonardo Daronco <leonardodaro...@gmail.com>
wrote:
> > > How can i bind a userid with a username and and attende passwort.
> > > Till now there is one url for all attendes with the same passwort and
> the
> > > same base url.
> > > How can i use the new feature to send out join urls, which can't be
> copied
> > > (means reuse the same url in paralell) and make it impossible or at
> least
> > > difficlut tu guess join urls?
>
> > >> Hi cforce,
>
> > >> With a bit more thought ... BigBlueButton could reject the join URL if
> > >> a user with the same userID is already in the meeting. If you have
> > >> two accounts on your server with the name 'cforce', but they both have
> > >> different IDs in your system, both could still join.
>
> > >> Since the userID parameter is optional, a 3rd party application could
> > >> omit the userID and essentially disable such a check.
>
> > >> Regards,... Fred
>