Web services

Moodle 2.0

Introduction

This page described the Web Services module implemented for Moodle 2.0
The official discussion forum is here
The tracker issue is here: MDL-12886
This module is been implemented by Moodle HQ and DFWS Team.

Implementation

The Web Services module has been conceived in order to be ported to different Moodle versions and for different projects. The objective is to support multiple web service protocols (REST, SOAP, XML-RPC and AMF). Adding support for a new protocol should be relatively easy.

How it works

This following example works but it will not be the unique way to access web services. Please have a look to the External services security page for more details.

1. The client sends a username and password to the web service protocol server script.
2. The protocol server returns a session token for that user account (how this is sent depends on the protocol).
3. The client calls a particular web service function including the session token.
4. The protocol server uses the token to check that the web service session is still active.
5. The protocol server call the matching external function, located in a externallib.php file inside the relevant module.
6. The external function checks that the current user has_capability to do this operation.
7. The external function calls the matching Moodle core function (in lib.php usually).
8. The core function can return a result to the external function.
9. The external function will return a result to the protocol server.
10. The protocol server returns the result to the client.

Web description format

All functions that can be called via web services can be declared in an externallib.php file somewhere. The description of the functions that can be called, and what parameters they require, is defined in the Service description page.

Web services technical documentation

In order to facilitate a Moodle web service client implementation, every Moodle sites will provide a page listing all function descriptions. This page also gives some useful advice for any supported protocol. To call this page: your_moodle/webservice/wsdoc.php?protocol=soap

API - Function list

The web service functions are listed here. (obsolete)

Authentication

External application

Clients needing to use a web service will need a Moodle user account with the 'moodle/site:usewebservices' capability enabled. After the first login with username and password the session is retained with a token that gets passed with every web service request (until the session expires).

The Moodle administrator can control access to the site using the 'Security -> Web services' page, which contains settings for:

• enabling/disabling particular protocols (SOAP, REST, AMF, XMLRPC, ...)
• configure protocol-specific settings (though we can't think of any such settings)
• configure system-wide default settings (stored in config table):

1. IP whitelist
2. Anything else?

• configure per-user settings (stored in user_preferences):

1. IP whitelist
2. Anything else?

Each protocol will call a webservice authentication function before allowing access, which will:

1. Check that particular protocol is enabled for the system
2. Authenticate the user using username/password and normal auth plugins (internal, LDAP etc)
3. Check that the user has 'moodle/site:usewebservices' at SYSTEM level.
4. Check the per-user restrictions, if there are any, else check the system settings
5. Create a session and return a token for the web service protocol to use.

This is probably enough (an auth/webservice is not necessary).

Embedded application

By embedded application, we consider Moodle module or blocks containing a Flash object / other client side code. These new modules or blocks are created by the embedded application creator.
To make it easy to have embedded apps communicate with Moodle, each time the user loads a page with an embedded application, the user should not have to enter his password.

Actual Mechanics - step by step of a web service call and authentication for an embedded app

1. The php page with the embedded app is called.
2. In the php script a function is called to generate a token :
   • this include an array of functions that the token allows access to. Eg. [0]=>'user/' => 'get_users',[1]=>'forum/' => 'get_forums', [3]=>'mod/{modname}/' => '*',
   • we restrict the access as much as possible.
   • Probably for an activity or block for example the token would only allow access to the services for that block.
3. The token is passed into the clientside app through appropriate html - in the case of Flash through Flashvars.
4. When the client calls the web service the token is passed as well as 'credentials'.
5. Moodle recognizes the user from the token. Config.php has a fork in it and sets up the USER and SESSION variables appropriately using the token and not the cookies - tricky.

Security

In order to minimize security risk :

• we can make the tokens expire afer a certain period of inactivity of the client app.
• we can limit the services that the token allows access to. I would suggest that we limit by path of external.php and also to functions within the external.php file.

Keeping other data on server side

It is usually the case that module id and such is passed to Moodle in the url. In the case of web service calls I think it would be a good idea to store perhaps the contextid on the server side associated with the token. This would increase security.

So for example for grading an activity we have a web service {activityname}_grade(). Since we have already stored the context id on the server we know the grade is passed is for such and such an activity. We do not pass the contextid as a parameter in the web service call and a web service call cannot be spoofed to pass a grade for another activity once the user has a token.

See also

• External services security
• External services description