# Probe: A Framework for Serious Games in Telecrabilitation
## Appendix A
### Server Application  
Each Proteo server exposes a REST interface with base endpoints (login/admin/edit module) and specific endpoints, depending on the active plugins. Each plugin operates independently but requires at least two GET endpoints: plugin_name/info and plugin_name/permissions. The first provides service information: the plugin version, whether the plugin is working, and the number of tickets it offers. The second returns an array of strings, with each string being a permission that the plugin exposes. The plugin computation is transparent to Proteo, which will only take care of assigning permissions to individual users. The server application is composed of several modules that will be briefly described in the following. Security module. Proteo implements a security mechanism in every REST call that consists of two components:  
* A call-based authentication system, based on keyed-hash message authentication codes (HMAC) and tokens;
* A plugin-oriented permission management. During the login process, the client generates an HMAC using the password entered by the user, and the client tries to generate the same HMAC using the password stored locally; if the two HMACs match, the server generates a token and sends it to the client. All subsequent client requests must contain an HMAC generated with a common key known to both the client, the server, and the token (see Figure A2). The token is generated by encrypting (with a key owned by the server) information on the user's identity and the token expiring date so that the client can connect to several servers without storing copies of the user's authorization to each server. Because of the scriptable nature of server-side plugins, it was necessary to develop a flexible structure for permissions. In practice, each plugin exposes a list of permissions to the server. These permissions are transparent to the server, but they are assigned to users via the admin module. At each REST call, the server passes the user ID to the plugin and the list of permissions that the user has. The plugin will then act appropriately according to the received permissions. Login module. A login request from the client is made via the [POST/login] call, this call can have two results:  
* If the credentials are missing (or incorrect), a Lua script is returned that allows a login page to be displayed with the possibility of registering or recovering a lost password. This interface is written using the client's graphical API and can be modified to adapt it graphically and functionally to requirements;
* The login is successful, and the requested script is returned (together with the token, see security module). Admin module. An administration interface can be accessed through a [GET/admin] call or through a login request. This script-based interface can also be modified, but to keep the main part of the implementation constant, the administration functions are part of a library. In addition, the library makes it transparent to the plugin which method is used to save the administration information. In the current version, the administration database is stored via SQLite. Through the administration module it is possible:  
* To activate or deactivate plugins that the server loads at start-up;
* To create and deactivate users;
* To change user passwords;To edit user permissions. During installation, there is only one user 'admin' with a password 'admin' who can access the script 'admin'. As a result, after the first installation, it is possible to add users and manage permissions. Plugin manager module. Each plugin consists of several access endpoints, such as the one shown in Figure A3:  
```
proteo.route.get(\"Plugin_name/helloworld/hi/:name\", function(username,permission,data,param) localresponse={} response[\"hello\"]=\"Hi\"..username..\"and\"..param[\"name\"] returnjson.encode(response) end }
```  
Figure A3. Proteo endpoint example. The routing system is very simple. Each endpoint is defined by a verb (in the example: GET), a path, and a function.