Home > Development, DOULS, Moodle > OpenSocial (Google) Gadgets that connect to Moodle

OpenSocial (Google) Gadgets that connect to Moodle

November 16th, 2010

As a part of the DOULS project we are planning to develop a range of gadgets that will connect to our Moodle VLE; providing information and features from the system to students within iGoogle and other OpenSocial platforms. 

Introducing this connection between an external platform and the VLE presents a number of issues around the security, administration and development of this integration. In the project we have attempted to address these issues through the development of an OpenSocial Moodle 2 plugin; a set of code libraries, tools and services to facilitate the delivery, administration and connectivity of OpenSocial gadgets within Moodle. This plugin is currently in development and will be released to the Moodle community along with accompanying gadgets towards the end of the project. 

The plugin will include the following features: 

Gadget XML delivery

Having gadget XML tied to the VLE has a number of advantages over hosting elsewhere. 

From a development point of view it makes sense as the gadgets we are producing are tied to functionality in Moodle; if Moodle code for that functionality changes then it may have an affect on our gadget, if the code is all in one repository (git, cvs, etc) then it’s easier to manage that process. 

When deploying our gadget for testing we may wish to point to one of the many copies of the VLE being run (development, test, live). By delivering the gadget XML via Moodle we can automatically insert the server address into the XML so that all references to the VLE in the code point to the correct location. This also makes it easy to distribute the gadget code to other Moodle users as they won’t need to manually update XML files to point to their server. 

The final advantage is that we can insert dynamic content into the XML. Although this can be achieved using techniques such as ‘proxied content’ by using a standard OpenSocial XML file and dynamically adding content we can make simple changes such as adding in security tokens or updating release revisions. 

Request verification

It is important to check requests that originate from OpenSocial containers are valid. Ensuring requests originating from gadgets are signed using OAuth means that at the application (Moodle) end we can ensure that the request has not been tampered with. This process is detailed on the OpenSocial wiki in the article ‘Introduction to Signed Requests’. 

The plugin has a library to deal with verifying OpenSocial requests (using open source OAuth php code), including the management of container certificates and consumer keys (which are stored in the Moodle database). 

User mapping

We want to produce a number of gadgets that show users VLE information within an OpenSocial Network (such as iGoogle). 

A key aspect of this functionality is identifying the mapping of a user account between the two systems. So the application (Moodle) needs to know that when OpenSocial user ‘student1001xx’ requests data then we need to return the data for ‘Stu Dent’. 

This situation is common with applications using OAuth and a solution could be easily implemented using this protocol. 

However, Moodle does not support OAuth (as a service provider). We could of course add support for this, but that would be quite a large development and we can achieve similar functionality using other methods. 

Using the general approach you would use with OAuth we map OpenSocial to Moodle users using the following process: 

  1. Gadget loads and makes a signed, non-cached, AJAX request to Moodle sending Owner and Viewer IDs (using osapi.http.get).
  2. Moodle verifies the request and then checks if a mapping exists in the database (against OpenSocial Owner ID and container).
  3. If there is no match and the Owner and Viewer IDs match then a login URL is created that includes a token that can be used to check authenticity of the login request.
  4. The response is return in JSON format.
  5. The gadget checks the response and if a login URL has been returned then the user is shown a link to this prompting them to sign-in.
  6. On selecting the link a pop-up is launched taking the user to the login URL.
  7. The login page is a Moodle page that requires the user to be logged in to the VLE. The page checks that a valid token has been sent and that the user mapping requested does not already exist.
  8. The user is displayed information about what the sign-in process means (gadget is trying to access data etc) and then given the option to accept.
  9. On accepting the mapping is created in the Moodle database and the window is closed.
  10. The gadget then repeats step 1, this time the user exists and so the gadget can continue.

Web services security layer

The main focus of the DOULS project is to ‘distribute’ the VLE. By using web services as the main point of interaction between the gadgets and the VLE there is a platform available to re-use these services in other developments.  

For example, we might have a gadget that displays a student’s course study planner; if the data to produce the output is obtained using a web service then that service could be used by another development e.g. a mobile app. 

Moodle 2 has a web services layer and we plan to create a number of services that will provide the data that the gadgets require (calling either HTTP REST or JSON services). The web services layer provides security in the form of token authentication (a unique token for each user). 

When we start to use the web services layer in gadgets then a number of problems start to surface: 

  1. Gadgets are HTML and JavaScript, any code can be manipulated. If a user has permission to access Moodle web services there is nothing to stop them maliciously changing requests e.g. changing the method call to one you might not want them to be able to do in this context (particularly when viewing a gadget on someone else’s profile page).
  2. How does the gadget know what the web services authentication token is? If we have one user token for all that is exposed then that isn’t secure as you could use this token to make request against another user. If every user has their own token how do users get this and enter it in the gadget?
  3. How do we manage permission to access the web services in Moodle? There could be a large administrative overhead to manage users if they all have individual web service tokens.

The plugin attempts to solve these problems by providing a layer that sits in-between the gadget and Moodle web services. Within this layer we can: 

  1. Verify the OpenSocial request using OAuth and so know who the ‘owner’ of the gadget is
  2. Check the correct method is being called using a token sent with the request (this is inserted using the gadget XML delivery feature)
  3. Check user mapping and ensure only data relating to gadget ‘owner’ is being requested
  4. Potentially block requests that are not appropriate in the current context e.g. where owner and viewer are not the same person.
  5. Call the Moodle web service using the authentication details of a single ‘system web service’ account.

Using this layer administration and security is much improved as there is a single account handling gadget web services so permissions can be tailored specifically for this account role. 

admin settings screen for the plugin

Config settings for the plugin in Moodle site admin

Categories: Development, DOULS, Moodle Tags:
  1. No comments yet.
Comments are closed.