<body><divclass="container"><h1id="rest-api-plugin-readme">REST API Plugin Readme</h1>
<body><divclass="container"><h1id="rest-api-plugin-readme">REST API Plugin Readme</h1>
<p>The REST API Plugin provides the ability to manage system properties by sending an HTTP request to the server. This plugin’s functionality is useful for applications that need to administer Openfire outside of the Openfire admin console.</p>
<p>The REST API Plugin provides the ability to manage Openfire by sending an REST/HTTP request to the server. This plugin’s functionality is useful for applications that need to administer Openfire outside of the Openfire admin console.</p>
<li><ahref="#using-the-plugin">Using the Plugin</a></li>
<li><ahref="#sample-html">Sample HTML</a></li>
<li><ahref="#server-reply">Server Reply</a></li>
</ul>
</ul>
</li>
</li>
</ul>
</ul>
</div>
</div>
</p>
</p>
<h2id="feature-list">Feature list</h2>
<h2id="feature-list">Feature list</h2>
<ul>
<ul>
<li>Get overview over all or specific user and to create, update or delete a user</li>
<li>Get overview over all user roster entries and to add, update or delete a roster entry</li>
<li>Add user to a group and remove a user from a group</li>
<li>Lockout or unlock the user (enable / disable)</li>
<li>Get overview over all or specific system properties and to create, update or delete system property</li>
<li>Get overview over all or specific system properties and to create, update or delete system property</li>
<li>Get overview over all or specific chat room and to create, update or delete a chat room</li>
</ul>
</ul>
<h2id="installation">Installation</h2>
<h2id="installation">Installation</h2>
<p>Copy restAPI.jar into the plugins directory of your Openfire server. The plugin will then be automatically deployed. To upgrade to a new version, copy the new restAPI.jar file over the existing file.</p>
<p>Copy restAPI.jar into the plugins directory of your Openfire server. The plugin will then be automatically deployed. To upgrade to a new version, copy the new restAPI.jar file over the existing file.</p>
<h2id="explanation-of-rest">Explanation of REST</h2>
<h2id="explanation-of-rest">Explanation of REST</h2>
<p>To provide a standard way of accessing the data the plugin is using REST.</p>
<p>To provide a standard way of accessing the data the plugin is using REST.</p>
<p>All REST Endpoint are secured by <ahref="http://en.wikipedia.org/wiki/Basic_access_authentication">Basic HTTP Authentication</a> or by shared secret key. The configuration can be done in Openfire Admin console under Server > Server Settings > REST API.</p>
<p>All REST Endpoint are secured and must be authenticated. There are two ways to authenticate: </p>
<p>Endpoint to get information over specific system property</p>
<table>
<thead>
<tr>
<th>Parameter</th>
<th>Optional</th>
<th>Description</th>
</tr>
</thead>
<tbody><tr>
<td>roomName</td>
<td>No</td>
<td>The name/id of the room. Can only contains lowercase and alphanumeric characters.</td>
</tr>
<tr>
<td>naturalName</td>
<td>No</td>
<td>Also the name of the room, but can contains non alphanumeric characters. It’s mainly used for users while discovering rooms hosted by the Multi-User Chat service.</td>
</tr>
<tr>
<td>description</td>
<td>No</td>
<td>Description text of the room.</td>
</tr>
<tr>
<td>password</td>
<td>Yes</td>
<td>The password that the user must provide to enter the room</td>
</tr>
<tr>
<td>creationDate</td>
<td>Yes</td>
<td>The date when the room was created. Will be automatically set by creation. Example: 2014-07-10T09:49:12.411+02:00</td>
</tr>
<tr>
<td>modificationDate</td>
<td>Yes</td>
<td>The last date when the room’s configuration was modified. If the room’s configuration was never modified then the initial value will be the same as the creation date. Will be automatically set by update. Example: 2014-07-10T09:49:12.411+02:00</td>
</tr>
<tr>
<td>maxUsers</td>
<td>Yes</td>
<td>the maximum number of occupants that can be simultaneously in the room. 0 means unlimited number of occupants.</td>
</tr>
<tr>
<td>persistent</td>
<td>Yes</td>
<td>Can be “true” or “false”. Persistent rooms are saved to the database to make their configurations persistent together with the affiliation of the users. Otherwise the room will be destroyed if the last occupant leave the room.</td>
</tr>
<tr>
<td>publicRoom</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if the room is searchable and visible through service discovery.</td>
</tr>
<tr>
<td>registrationEnabled</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if users are allowed to register with the room. By default, room registration is enabled.</td>
</tr>
<tr>
<td>canAnyoneDiscoverJID</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if every presence packet will include the JID of every occupant.</td>
</tr>
<tr>
<td>canOccupantsChangeSubject</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if participants are allowed to change the room’s subject.</td>
</tr>
<tr>
<td>canOccupantsInvite</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if occupants can invite other users to the room. If the room does not require an invitation to enter (i.e. is not members-only) then any occupant can send invitations. On the other hand, if the room is members-only and occupants cannot send invitation then only the room owners and admins are allowed to send invitations.</td>
</tr>
<tr>
<td>canChangeNickname</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if room occupants are allowed to change their nicknames in the room. By default, occupants are allowed to change their nicknames.</td>
</tr>
<tr>
<td>logEnabled</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if the room’s conversation is being logged. If logging is activated the room conversation will be saved to the database every couple of minutes. The saving frequency is the same for all the rooms and can be configured by changing the property “xmpp.muc.tasks.log.timeout”.</td>
</tr>
<tr>
<td>loginRestrictedToNickname</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if registered users can only join the room using their registered nickname. By default, registered users can join the room using any nickname.</td>
</tr>
<tr>
<td>membersOnly</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if the room requires an invitation to enter. That is if the room is members-only.</td>
</tr>
<tr>
<td>moderated</td>
<td>Yes</td>
<td>Can be “true” or “false”. True if the room in which only those with “voice” may send messages to all occupants.</td>
</tr>
<tr>
<td>broadcastPresenceRoles</td>
<td>Yes</td>
<td>The list of roles of which presence will be broadcasted to the rest of the occupants.</td>
</tr>
<tr>
<td>owners</td>
<td>Yes</td>
<td>A collection with the current list of owners. The collection contains the bareJID of the users with owner affiliation.</td>
</tr>
<tr>
<td>admins</td>
<td>Yes</td>
<td>A collection with the current list of admins. The collection contains the bareJID of the users with admin affiliation.</td>
</tr>
<tr>
<td>members</td>
<td>Yes</td>
<td>A collection with the current list of room members. The collection contains the bareJID of the users with member affiliation. If the room is not members-only then the list will contain the users that registered with the room and therefore they may have reserved a nickname.</td>
</tr>
<tr>
<td>outcasts</td>
<td>Yes</td>
<td>A collection with the current list of outcast users. An outcast user is not allowed to join the room again. The collection contains the bareJID of the users with outcast affiliation.</td>
</tr>
</tbody></table>
<p><strong>Payload:</strong> none <br>
<strong>Return value:</strong> System property</p>
</span><spanclass="str">"name"</span><spanclass="pun">:</span><spanclass="pln"></span><spanclass="str">"Test User edit"</span><spanclass="pun">,</span><spanclass="pln">
<h1id="deprecated-user-service-plugin-readme">(Deprecated) User Service Plugin Readme</h1>
<h2id="overview">Overview</h2>
<p>The User Service Plugin provides the ability to add,edit,delete users and manage their rosters by sending an http request to the server. It is intended to be used by applications automating the user administration process. This plugin’s functionality is useful for applications that need to administer users outside of the Openfire admin console. An example of such an application might be a live sports reporting application that uses XMPP as its transport, and creates/deletes users according to the receipt, or non receipt, of a subscription fee.</p>
<h2id="installation-1">Installation</h2>
<p>Copy userservice.jar into the plugins directory of your Openfire server. The plugin will then be automatically deployed. To upgrade to a new version, copy the new userservice.jar file over the existing file.</p>
<h2id="configuration">Configuration</h2>
<p>Access to the service is restricted with a “secret” that can be viewed and set from the User Service page in the Openfire admin console. This page is located on the admin console under “Server” and then “Server Settings”. This should really only be considered weak security. The plugin was initially written with the assumption that http access to the Openfire service was only available to trusted machines. In the case of the plugin’s author, a web application running on the same server as Openfire makes the request.</p>
<h2id="using-the-plugin">Using the Plugin</h2>
<p>To administer users, submit HTTP requests to the userservice service. The service address is [hostname]plugins/restapi/userservice. For example, if your server name is “example.com”, the URL is <ahref="http://example.com/plugins/restapi/userservice">http://example.com/plugins/restapi/userservice</a></p>
<p>The following parameters can be passed into the request:</p>
<table>
<thead>
<tr>
<th>Name</th>
<th></th>
<th>Description</th>
</tr>
</thead>
<tbody><tr>
<td>type</td>
<td>Required</td>
<td>The admin service required. Possible values are ‘add’, ‘delete’, ‘update’, ‘enable’, ‘disable’, ‘add_roster’, ‘update_roster’, ‘delete_roster’, ‘grouplist’, ‘usergrouplist’.</td>
</tr>
<tr>
<td>secret</td>
<td>Required</td>
<td>The secret key that allows access to the User Service.</td>
</tr>
<tr>
<td>username</td>
<td>Required</td>
<td>The username of the user to ‘add’, ‘delete’, ‘update’, ‘enable’, ‘disable’, ‘add_roster’, ‘update_roster’, ‘delete_roster’. ie the part before the @ symbol.</td>
</tr>
<tr>
<td>password</td>
<td>Required for ‘add’ operation</td>
<td>The password of the new user or the user being updated.</td>
</tr>
<tr>
<td>name</td>
<td>Optional</td>
<td>The display name of the new user or the user being updated. For ‘add_roster’, ‘update_roster’ operations specifies the nickname of the roster item.</td>
</tr>
<tr>
<td>email</td>
<td>Optional</td>
<td>The email address of the new user or the user being updated.</td>
</tr>
<tr>
<td>groups</td>
<td>Optional</td>
<td>List of groups where the user is a member. Values are comma delimited. When used with types “add” or “update”, it adds the user to shared groups and auto-creates new groups. When used with ‘add_roster’ and ‘update_roster’, it adds the user to roster groups provided the group name does not clash with an existing shared group.</td>
</tr>
<tr>
<td>item_jid</td>
<td>Required for ‘add_roster’, ‘update_roster’, ‘delete_roster’ operations.</td>
<td>The JID of the roster item</td>
</tr>
<tr>
<td>subscription</td>
<td>Optional</td>
<td>Type of subscription for ‘add_roster’, ‘update_roster’ operations. Possible numeric values are: -1(remove), 0(none), 1(to), 2(from), 3(both).</td>
<p>* When sending double characters (Chinese/Japanese/Korean etc) you should URLEncode the string as utf8. <br>
In Java this is done like this <br>
URLEncoder.encode(username, “UTF-8”)); <br>
If the strings are encoded incorrectly, double byte characters will look garbeled in the Admin Console.</p>
<h2id="server-reply">Server Reply</h2>
<p>The server will reply to all User Service requests with an XML result page. If the request was processed successfully the return will be a “result” element with a text body of “OK”, or an XML grouplist formatted like in the example for “grouplist” and “usergrouplist” above. If the request was unsuccessful, the return will be an “error” element with a text body of one of the following error strings.</p>
<table>
<thead>
<tr>
<th>Error String</th>
<th>Description</th>
</tr>
</thead>
<tbody><tr>
<td>IllegalArgumentException</td>
<td>One of the parameters passed in to the User Service was bad.</td>
</tr>
<tr>
<td>UserNotFoundException</td>
<td>No user of the name specified, for a delete or update operation, exists on this server. For ‘update_roster’ operation, roster item to be updated was not found.</td>
</tr>
<tr>
<td>UserAlreadyExistsException</td>
<td>A user with the same name as the user about to be added, already exists. For ‘add_roster’ operation, roster item with the same JID already exists.</td>
</tr>
<tr>
<td>RequestNotAuthorised</td>
<td>The supplied secret does not match the secret specified in the Admin Console or the requester is not a valid IP address.</td>
</tr>
<tr>
<td>UserServiceDisabled</td>
<td>The User Service is currently set to disabled in the Admin Console.</td>
</tr>
<tr>
<td>SharedGroupException</td>
<td>Roster item can not be added/deleted to/from a shared group for operations with roster.</td>
