The account tag is the root of the XML message.
It contains your Apideo key, as an attribute.
In the account tag, you can put one default tag and several token tags.
The default tag contains the default rule that will be applied if no tokens are passed by the user.
Each token tag contains the rules to apply for a token.
The "defaultroom" tag contains the list of rules to be applied by default, if no rules are found for a specific room.
First, Apideo will check the "room" tags, and if no room matches the room joined, then the "defaultroom" tag applies.
The "listener" tag is used to decide whether a user can listen to a kind of events or not.
The "category" attribute contains the listener name that is allowed or denied.
Alternatively, you can use the "categoryregex" attribute to pass a regex in parameter.
The "access" attribute decides whether the rule will allow or deny access.
The listeners tag is used to decide whether the user is by default allowed to listen to events or not.
It has a "defaultAccess" attribute that can be either "allow" or "reject".
The default behaviour can be overloaded by individual "listener" tags.
The "listeners" tag can contain any number of "listener" tag.
The "listener" tags are applied from top to bottom. Apideo will stop going through tags after one tag is matched, so the order is important.
Here is an example:
<listeners defaultAccess="reject">
<listener regex="event_[.]*" access="allow" />
<listener name="event_42" access="reject" />
</listeners>
In the example above, the second "listener" rule will never be applied, because the first regex will always be matched first. So this code will result in an access allowed:
<pre>
// Access will be allowed
room.registerListener(myListener, "event_42")
</pre>
<p> However, access to the listener will be denied if you put the rules in the other way.</p>
<listeners defaultAccess="reject">
<listener name="event_42" access="reject" />
<listener regex="event_[.]*" access="allow" />
</listeners>
The "room" tag contains rules to be applied for a specific room or a set of rules.
The "room" tag has a "name" attribute to tell the name of the room.
Alternatively, you can use the "regex" attribute to use a regular expression that matches the name of the room.
Finally, the "access" attribute can have 2 values:
- "allow" to allow access to the room
- "reject" to deny access to the room
The "sendEvent" tag is used to decide whether a user can send a kind of events or not.
The "category" attribute contains the listener name that is allowed or denied.
Alternatively, you can use the "categoryregex" attribute to pass a regex in parameter.
The "access" attribute decides whether the rule will allow or deny access.
Finally, the "filter" attribute contains Javascript code that must be matched for the filter to be applied.
In the Javascript code, you can access the object sent using the "obj" variable.
Below is an example:
<sendEvents defaultAccess="reject">
<sendEvent name="mylistener" filter="obj.type=='manager'" access="allow" />
</sendEvents>
In this sample, by default, the user cannot send events.
However, he can send events if the event listener is "mylistener" and if the object passed in parameter contains "type == 'manager'".
<div class="apideogood">
So this code would be correct:
<pre> room.sendEvent({type:'manager', text:'Hello!'},"mylistener")</pre>
</div>
<div class="apideoerror">
This code would be denied by Apideo:
<pre> room.sendEvent({type:'administrator', text:'Hello!'},"mylistener")</pre>
</div>
The sendEvents tag is used to decide whether the user is by default allowed to send events or not.
It has a "defaultAccess" attribute that can be either "allow" or "reject".
The default behaviour can be overloaded by individual "sendEvent" tags.
The "sendEvents" tag can contain any number of "sendEvent" tag.
The "sendEvent" tags are applied from top to bottom. Apideo will stop going through tags after one tag is matched, so the order is important.
Here is an example:
<sendEvents defaultAccess="reject">
<sendEvent regex="event_[.]*" access="allow" />
<sendEvent name="event_42" access="reject" />
</sendEvents>
In the example above, the second "sendEvent" rule will never be applied, because the first regex will always be matched first. So this code will result in an access allowed:
<pre>
// Access will be allowed
room.sendEvent({}, "event_42")
</pre>
However, access will be denied if you put the rules in the other way.
<sendEvents defaultAccess="reject">
<sendEvent name="event_42" access="reject" />
<sendEvent regex="event_[.]*" access="allow" />
</sendEvents>
The "startCamera" tag is used to decide whether a user can send a stream or not.
The "name" attribute contains the name of the stream that is allowed or denied.
Alternatively, you can use the "regex" attribute to pass a regex in parameter.
The "access" attribute decides whether the rule will allow or deny access (can be "allow" or "reject").
The startCameras tag is used to decide whether the user is by default allowed to send a stream or not.
It has a "defaultAccess" attribute that can be either "allow" or "reject".
The default behaviour can be overloaded by individual "startCamera" tags.
The startCameras" tag can contain any number of "startCamera" tag.
The "startCamera" tags are applied from top to bottom. Apideo will stop going through tags after one tag is matched, so the order is important.
Here is an example:
<startCameras defaultAccess="reject">
<startCamera regex="stream_[.]*" access="allow" />
<startCamera name="stream_42" access="reject" />
</startCameras>
In the example above, the second "startCamera" rule will never be applied, because the first regex will always be matched first. So this code will result in an access allowed:
<pre>
// Access will be denied
room.startCamera("cameraDiv", "stream_42")
</pre>
However, access will be denied if you put the rules in the other way.
<startCameras defaultAccess="reject">
<startCamera name="stream_42" access="reject" />
<startCamera regex="stream_[.]*" access="allow" />
</startCameras>
The <token> tag contains the security rules to be applied for one token. The <token> tag has 2 attributes: "name" (the name of the token) and "ttl" (the time to live, in seconds for the token).
It is your responsibility to generate a token name. Please be sure to generate a token name random enough so it cannot be guessed easily.
The userlist tag is used to decide whether the user is by default allowed to view the list of users that are part of the room he is in.
It has an "access" attribute that can be either "allow" or "reject".
If access to the user list is rejected by the token, a call to the "forEachUser" method will return an error:
// Triggers a security error:
myroom.forEachUser(function(userId, userObj) { ... });
Finally, the userlist tag contains a "filter" attribute. You can only use this attribute if "access" is set to "allow".
Using the filter, you can decide that your user will be able to see only a part of the users that are connected to the room.
The filter is a one-line Javascript code that must matched the users profiles.
In the Javascript code, you can access the user profiles using the "obj" variable.
Below is an example:
<userlist defaultAccess="accept" filter="obj.type=='manager'" />
In this sample; by default, the user cannot only see the users who have a profile with type=='manager'.
<div class="apideogood">
So if another user connects with this profile, he will be visible to the first user:
<pre> conn.joinRoom('myRoom', {type:'manager'});</pre>
</div>
<div class="apideoerror">
However, the user below would not be visible to the first user:
<pre> room.joinRoom('myRoom', {type:'user'});</pre>
</div>
The userprofile tag is used to decide whether the user is by default allowed to submit a user profile to the list of users that are part of the room he is in.
It has an "access" attribute that can be either "allow" or "reject".
If access to the user profile is rejected by the token, any call to "joinRoom" must pass "null" as the second argument:
// The second parameter (the user profile) must be null if <userprofile access='reject'>:
myroom.joinRoom('myroom', null, 'AJVFDSOISDLDSKLDSF');
Finally, the userprofile tag contains a "filter" attribute. You can only use this attribute if "access" is set to "allow".
Using the filter, you can decide that your user will be able to submit a profile only if it respects a number of conditions.
The filter is a one-line Javascript code that must matched the users profiles.
In the Javascript code, you can access the user profiles using the "obj" variable.
Below is an example:
<userprofile defaultAccess="accept" filter="obj.type=='user'" />
In this sample, the user cannot only join the room if he sets his type to "user".
<div class="apideogood">
So this will be ok:
<pre> conn.joinRoom('myRoom', {type:'user'}, 'AJVFDSOISDLDSKLDSF');</pre>
</div>
<div class="apideoerror">
And this will be denied access:
<pre> room.joinRoom('myRoom', {type:'manager'}, 'AJVFDSOISDLDSKLDSF');</pre>
</div>
The "viewStream" tag is used to decide whether a user can send a stream or not.
The "name" attribute contains the name of the stream that is allowed or denied.
Alternatively, you can use the "regex" attribute to pass a regex in parameter.
The "access" attribute decides whether the rule will allow or deny access (can be "allow" or "reject").
The "viewStreams" tag is used to decide whether the user is by default allowed to view a stream or not.
It has a "defaultAccess" attribute that can be either "allow" or "reject".
The default behaviour can be overloaded by individual "viewStream" tags.
The "viewStreams" tag can contain any number of "viewStream" tag.
The "viewStream" tags are applied from top to bottom. Apideo will stop going through tags after one tag is matched, so the order is important.
Here is an example:
<viewStreams defaultAccess="reject">
<viewStream regex="stream_[.]*" access="allow" />
<viewStream name="stream_42" access="reject" />
</viewStreams>
In the example above, the second "viewStream" rule will never be applied, because the first regex will always be matched first. So this code will result in an access allowed:
<pre>
// Access will be denied
room.viewStream("cameraDiv", "stream_42")
</pre>
However, access will be denied if you put the rules in the other way.
<viewStreams defaultAccess="reject">
<viewStream name="stream_42" access="reject" />
<viewStream regex="stream_[.]*" access="allow" />
</viewStreams>
The <default> tag contains the security rules to be applied by default.
If the user does provide a token inside <code>joinRoom</code> or if the token passed in parameter does not exist or if the token rules do not specify anything meaningful, the default rule will be used instead.
Please note that if the default rule does not explicitly forbid an action, it will be allowed.
For instance, if you do not specifically specify that sending events is not allowed, all users who do not provide a token will be able to send events.
The XML Instance Representation table above shows the schema component's content as an XML instance.
The minimum and maximum occurrence of elements and attributes are provided in square brackets, e.g. [0..1].
Model group information are shown in gray, e.g. Start Choice ... End Choice.
For type derivations, the elements and attributes that have been added to or changed from the base type's content are shown in bold.
If an element/attribute has a fixed value, the fixed value is shown in green, e.g. country="Australia".
Otherwise, the type of the element/attribute is displayed.
If the element/attribute's type is in the schema, a link is provided to it.
For local simple type definitions, the constraints are displayed in angle brackets, e.g. <<pattern = [1-9][0-9]{3}>>.
If a local element/attribute has documentation, it will be displayed in a window that pops up when the question mark inside the attribute or next to the element is clicked, e.g. <postcode>.
Abstract(Applies to complex type definitions and element declarations). An abstract element or complex type cannot used to validate an element instance. If there is a reference to an abstract element, only element declarations that can substitute the abstract element can be used to validate the instance. For references to abstract type definitions, only derived types can be used.
Collapse Whitespace PolicyReplace tab, line feed, and carriage return characters with space character (Unicode character 32). Then, collapse contiguous sequences of space characters into single space character, and remove leading and trailing space characters.
Disallowed Substitutions(Applies to element declarations). If substitution is specified, then substitution group members cannot be used in place of the given element declaration to validate element instances. If derivation methods, e.g. extension, restriction, are specified, then the given element declaration will not validate element instances that have types derived from the element declaration's type using the specified derivation methods. Normally, element instances can override their declaration's type by specifying an xsi:type attribute.
Nillable(Applies to element declarations). If an element declaration is nillable, instances can use the xsi:nil attribute. The xsi:nil attribute is the boolean attribute, nil, from the http://www.w3.org/2001/XMLSchema-instance namespace. If an element instance has an xsi:nil attribute set to true, it can be left empty, even though its element declaration may have required content.
Prohibited Derivations(Applies to type definitions). Derivation methods that cannot be used to create sub-types from a given type definition.
Prohibited Substitutions(Applies to complex type definitions). Prevents sub-types that have been derived using the specified derivation methods from validating element instances in place of the given type definition.
Replace Whitespace PolicyReplace tab, line feed, and carriage return characters with space character (Unicode character 32).
Substitution GroupElements that are members of a substitution group can be used wherever the head element of the substitution group is referenced.
Substitution Group Exclusions(Applies to element declarations). Prohibits element declarations from nominating themselves as being able to substitute a given element declaration, if they have types that are derived from the original element's type using the specified derivation methods.
Target NamespaceThe target namespace identifies the namespace that components in this schema belongs to. If no target namespace is provided, then the schema components do not belong to any namespace.