Category: WebLearn (Sakai)

Posted on

Sakai Entity Broker methods – the missing documentation

An attempt to collect together some understandable documentation on how to use the Sakai (@Oxford Sakai=WebLearn) Entity Broker (EB) methods in the face of continued frustration with Sakai documentation accessed via /direct/describe (@Oxford https://www.weblearn.ox.ac.uk/direct/describe).

I’m only going to cover methods to return JSON  as that’s all we ever use and am not bothering to describe the format of the returned JSON as it’s easier just to look at what’s returned in the browser.

  • Announcement
  • Assignment
  • Content
  • Forums (including Topic, Thread and Message)
  • Group
  • Lesson
  • Lessons
  • Membership
  • Polls
  • Portal-hierarchy
  • User

announcement

Gets the announcements for a site for the logged in user.

/direct/announcement/site/siteId.json

e.g @Oxford

https://weblearn.ox.ac.uk/direct/announcement/site/d1506490-a468-46ca-a915-417d9d11be2f.json

assignment

Gets the assignments for a site for the logged in user.

/direct/assignment/site/siteId.json

e.g @Oxford

https://weblearn.ox.ac.uk/direct/assignment/site/d1506490-a468-46ca-a915-417d9d11be2f.json

content

Gets the contents of the Resources tool.

/direct/content/resources/group/siteId[/subFolderPath].json[?depth=noOfSteps]

where:

  • subFolderPath (optional) is the path a subfolder (path relative to root of Resources)
  • noOfSteps (optional) is the no of ‘layers’ of content to return (seems to have a maximum value of 3?). If not specified defaults to 1.

e.g @Oxford

https://weblearn.ox.ac.uk/direct/content/resources/group/1e969f60-9ebf-48b7-bb0f-54f598de05da/Online%20assessments%20documents.json?depth=2

forums (including topic, thread and message)

Get all fora for a site:

/direct/forums/site/siteId.json

Get all topics for a forum:

/direct/forums/site/siteId/forum/forumId.json

Get all conversations for a topic:

/direct/forums/site/siteId/forum/forumId/topic/topicId.json

Get a fully populated conversation or message. This retrieves the message tree from the specified message downwards. If the messsageId is the top level message in a conversation, the entire conversation is returned:

/direct/forums/site/siteId/forum/forumId/topic/topicId/message/messsageId .json

…and to link directly to individual parts of forums:

For direct forum link url is :

/portal/hierarchytool/siteId/discussionForum/forum/dfForumDirect.jsf?forumId=forumId

Direct forum_topic link is :

/portal/hierarchytool/siteId/discussionForum/message/dfAllMessagesDirect.jsf?topicId=topicId

Direct link to individual message is :

/portal/hierarchytool/siteId/discussionForum/message/dfViewMessageDirect.jsf?messageId=messsageId &topicId=topicId&forumId=forumId

group

Get the membership of a group.

/direct/membership/group/groupId.json

whee groupId can be found by looking at the address of the page when editing a group in Siet Info | Manage Subgroups – may also be possible to find by name with /direct/site methods?

e.g @Oxford

https://weblearn.ox.ac.uk/direct/membership/group/8513fad8-656f-4265-9573-f00b8a781d02.json

lesson

Get the contents of a lesson.

/direct/lessons/lesson/lessonId.json

where lessonId is the id or entityId returned by direct/lessons (above)

e.g @Oxford

https://weblearn.ox.ac.uk/direct/lessons/lesson/35538.json

lessons

Get a list of the lessons in a site.

/direct/lessons/site/siteId.json

e.g @Oxford

https://weblearn.ox.ac.uk/direct/lessons/site/1e969f60-9ebf-48b7-bb0f-54f598de05da.json

Note that, in Sakai 11 at Oxford anyway, the lessons EB method will not currently (03/10/16) return lessons to access users – only those with elevated rights e.g for the same call:

As a maintainer:

{"entityPrefix": "lessons", "lessons_collection": [
    {
    "contentsURL": "https:\/\/weblearn.ox.ac.uk\/direct\/lessons\/lesson\/78676",
    "gradebookPoints": null,
    "id": 78676,
    "lessonTitle": "Module 1",
    "releaseDate": null,
    "hidden": false,
    "entityReference": "\/lessons\/78676",
    "entityURL": "https:\/\/weblearn.ox.ac.uk\/direct\/lessons\/78676",
    "entityId": "78676"
    }
]}

As an access user:

{"entityPrefix": "lessons", "lessons_collection": [

]}

membership

Get information about membership of a given user in a given site

/direct/membership/userId::site:siteId.json

where:

  • userId is the id (Sakai’s internal reference) of user about which you want info (obtainable for logged in user from user/current.json as below)
  • siteId  is the Sakai siteId.

e.g @Oxford

https://weblearn.ox.ac.uk/direct/membership/d00ca345-4e31-485c-00e9-0fc880da2dc0::site:d1506490-a468-46ca-a915-417d9d11be2f.json

polls

Can’t find any way to get a list of polls for a site!

Get poll text and options

/direct/polls/pollId/poll-view.json?includeOptions=true

where:

  • pollId is the id (Sakai’s internal reference) of the poll. This is most easily obtained by hovering over the poll name in the edit view and picking out the number(!)
  • includeOptions (boolean) specifies whether to also return the options for the poll and;
  • includeVotes (boolean) specifies whether to also return the votes cast

e.g @Oxford

https://weblearn.ox.ac.uk/direct/polls/pollId/poll-view.json?includeOptions=true

portal-hierarchy (maybe only @Oxford?)

Provides a list of all the sites (to which the user has access) under a given site – one level down only.

/direct/portal-hierarchy/site.json?portalpath=pathFromRoot

e.g @Oxford

https://weblearn.ox.ac.uk/direct/portal-hierarchy/site.json?portalpath=/medsci

user

Information about the logged-in user – mainly used to get interal Sakai id for use in other methods.

/direct/user/current.json

e.g @Oxford

https://weblearn.ox.ac.uk/direct/user/current.json

more..

I’ll try to remember to add to these as I use them.

Posted on

MSDLT Update May-Oct 2013

Teaching Excellence Project Award for mobile technology

New user-friendly interface for My Workspace Resources for Biomedical Sciences students in Sakai/WebLearn

Bringing Biochemistry TLTP software up to date

And progress with: online maths assessment; project choosing; clinical sign-off and the History of Medical Sciences website

Get your copy here: ETSGMSDLTNewsMaytoOct2013.

Posted on

The Basics of writing a Basic LTI Tool Provider

I hope this will be helpful for anyone just getting started with (Basic) LTI and wanting to create their first Tool Provider. Apologies for any abuse/misuse of the terminology – this is just how I understand it. To recap the two halves of an LTI launch:

Tool Consumer (TC) = An LTI-enabled VLE/LMS/other system that can make an LTI launch request. Generally (or at least the way we are using it), the TC manages user accounts/passwords, so that the Tool Provider doesn’t have to.
Tool Provider (TP) = an external tool that receives an LTI request from a TC and uses the launch data to work out what the user is able to see/do within the tool.

Useful links

I found the following useful when getting to grips with LTI and creating my first TP (in PHP):

Thanks of course to Dr Chuck and the rest of the LTI community for developing this specification and the above Classes, Tools and Tutorials.

Basic Implementation

The PHP Basic LTI class makes it very easy to do the LTI/OAuth bit of the TP. Here’s my pseudo-PHP code for the basic process:

//All of the LTI Launch data gets passed through in $_REQUEST
if(isset($_REQUEST['lti_message_type'])) {    //Is this an LTI Request?

    //We store oauth_consumer_key and secret pairs in our database, so we look the secret up here, but it can just be hard-coded (especially for testing)
    $secret = [secret];

    //Get BLTI class to do all the hard work (more explanation of these below)
    // - first parameter is the secret, which is required
    // - second parameter (defaults to true) tells BLTI whether to store the launch data is stored in the session ($_SESSION['_basic_lti_context'])
    // - third parameter (defaults to true) tells BLTI whether to redirect the user after successful validation
    $context = new BLTI($secret, true, false);

    //Deal with results from BLTI class 
    if($context->complete) exit(); //True if redirect was done by BLTI class
    if($context->valid) { //True if LTI request was verified
     //Let the user in
    }
}
else { //Not an LTI request, so either don't let this user in, or provide another way for them to authenticate, or show them only public content
}

Just to further explain the parameters passed when instantiating the BLTI class, the first argument is the secret, which is required and would usually be a string. Alternatively, you can pass through an associative array of database information (e.g. ‘table’ => ‘lti_keys’, ‘key_column’ => ‘oauth_consumer_key’), and the BLTI class will look up the secret from the database.

The second argument (true by default) tells the BLTI class whether to store the launch data in the session (from which it can be retrieved using $_SESSION[‘_basic_lti_context’]) and whether to try to automatically retrieve any stored LTI launch data if someone tries to access a tool without coming in through LTI. This means that if a user has initially come to a tool through LTI, then closes the browser tab containing the tool, and then goes directly back to the tool, without coming through LTI, as long as their session has not expired they will be allowed back into the tool, even though have not come through LTI. I would generally recommend keeping this as true, as I think this would usually be useful behaviour.

The third argument (true by default, but I generally set it to false) tells the BLTI class whether to do the redirect or not after validation of the request. Setting this to false will prevent it from doing the redirect.

I hope this is helpful. My understanding is pretty (cheap pun alert!) basic, so I would welcome any thoughts, queries, suggestions or corrections.

For further information/discussion of LTI, and how we have used it to allow access to our iCases system through WebLearn (our VLE), please see these posts:

Posted on

Allowing access to iCases through LTI

This post follows on from my Early Thoughts on LTI.

We have now fully implemented LTI for our iCases system. This has many benefits, including:

  • We no longer have to maintain authentication/permissions information within iCases, this can instead be done by WebLearn (Sakai), the Univeristy’s VLE.
  • Previously, it was only possible to log in to iCases if you had an Oxford Single Sign On username, so non-Oxford users had to use a single ‘anonymous’ account. That meant all non-Oxford users could see each other’s attempts and answers, and it was very difficult for them to pause and resume an attempt, due to the difficulty of finding the previous attempt among a long list of anonymous attempts.
  • iCases can be integrated into WebLearn making it very easy to add an iCase to a course.
  • Other institutions with a VLE/LMS that conforms to the LTI standard can easily use our public iCases.

We have already successfully made an iCase available to both Oxford and non-Oxford users through WebLearn/LTI, and are beginning to roll out our remaining iCases using this method. This includes making a number of iCases available publicly – see https://learntech.medsci.ox.ac.uk/wordpress-blog/?p=295.

As it currently works, the following is the process for adding an LTI Tool Provider to a site in WebLearn (the LTI Tool Consumer):

  1. Add a Basic LTI Tool to the site
  2. An individual with “Instructor” privileges (in WebLearn this means someone with a maintain/contribute role) can set up the Basic LTI Tool to point to the Tool Provider. This requires, at the very least, setting the URL and entering a key and secret (held/provided by us) into WebLearn.
  3. The Instructor can also set some launch/display settings. These settings include whether to open the Tool Provider in a new window and whether to pass information about the user, e.g. name/email address, to it, both of which we do.
  4. When the LTI Tool is launched, it sends a signed LTI request to the Tool Provider (i.e. iCases)

Turning iCases into an LTI Tool Provider wasn’t totally easy, but wasn’t as difficult as I had expected, and was made much easier by using the IMS Global Bsaic LTI PHP class – http://ims-dev.googlecode.com/svn/trunk/basiclti/php-simple/ims-blti/. The way I have got the LTI launch to work, at the Tool Provider end is a follows:

  1. Check that we have received an LTI request – iCases is set up so that it can only be accessed through LTI, although it would be possible to allow other access routes.
  2. Get the oauth_consumer_key from the launch data, and use this to look up the corresponding secret in a table to keys/secrets in our database.
  3. Create a new BLTI object (using the IMS Global class) which does all of the “is this a valid LTI launch?”/OAuth stuff for you.
  4. If this is the first time iCases has been launched from this context (i.e. a site in WebLearn), add the context to the database.
  5. If this is the first time that this user (defined by their WebLearn unique ID) has accessed iCases, add the user to the database.
  6. If this is the first time iCases has been launched from this context and the user has an Instructor role, allow them to choose an iCase to associate with this LTI tool instance. If this is the first launch from this context, and the user is not an Instructor, send them to an access denied page.
  7. Any future launches from this context will now send users directly to the associated iCase.
  8. As well as being the only ones who can link a Basic LTI Tool instance to an iCase, Instructors also get extra privileges within iCases, e.g. they can mark student attempts.

And that’s it! We are very excited by the options LTI opens up for us, in particular the fact that it enables us to make WebLearn a single, consistent route to many tools, and that we no longer have to worry about maintaining user accounts/passwords within our tools (which has security benefits for users). It would be possible to make Tool Providers appear as though they are actually part of WebLearn, although we haven’t done this for iCases.

We are anticipating LTI-ing a number of other tools in the near future, including CSlide and a project/module option choosing system – watch this space!

Posted on

CakePHP Session data being lost on redirect

Having successfully enabled access using LTI to a local version of iCases – see https://learntech.medsci.ox.ac.uk/wordpress-blog/?p=229 – I got it set up on a live server, assuming that it would work without any trouble. However, I was unable to login successfully through WebLearn, which is our Tool Consumer.

It turned out that this was due to the session data being lost when redirecting from the login page within the CakePHP app to the scenario page. Authentication using LTI relies on session data, as the LTI context information is saved to the session. Therefore, when the session data was lost, the app could no longer tell that the user had accessed it through a valid LTI request, and so the user was denied access.

I fixed this by changing Security.level in core.php to ‘low’ (it had previously been medium). From the CakePHP docs, this increases the multiplier for the ‘Session.timeout’ value (from 100 to 300) and disables (or, to be pedantic, does not enable) PHP’s session.referer_check. It seems to be the latter that was the problem. However, in the php.ini file we have ‘session.referer_check = ‘, which should mean that session.referer_check is not enabled anyway. So I am not sure why changing the security level had an effect, unless setting the Security.level to medium enables session.referer_check, even if it was not already enabled.

As far as I can tell from reading around, disabling session.referer_check should not cause any problems, as it is only possible to access the LTI-ed iCases through WebLearn. Checking that the LTI launch is valid includes checking that the launch request has come from a valid location.

Posted on

Early Thoughts on LTI

We have been investigating using the Learning Tools Interoperability (LTI) tool available through our VLE, WebLearn (Sakai), in order to authenticate users for various services that we provide (or are considering providing), including Rogo, iCases and OxPro.  We initially thought that this would mean we could take user/authentication control completely out of these systems, but unfortunately (in terms of ease, but fortunately in terms of security) it is not so easy.

The LTI specification has been created by the IMS Global Learning Consortium and uses OAuth to sign requests for accessing a tool. The Tool Provider (TP), e.g. Rogo, iCases or OxPro, stores a secret and an ‘oauth_consumer_key’ for each Tool Consumer (TC), e.g. WebLearn. When a tool is launched from the TC through LTI, a signed request is sent to the TP. The TP uses the oauth_consumer_key sent with the signed request to look up the secret, recreate the signature and check that the signatures match. Matching signatures results in a valid request, and the user is allowed to access the tool. If everything within the tool is available to every user this is as complicated as it gets. It is also possible to differentiate access rights based on a user’s role, which should (i.e. it is recommended by the LTI specification) be passed through in the LTI launch data. Both of these scenarios do not require any user information or privileges to be stored by the TP.

The situation gets more complicated when a user should only be allowed to access certain resources within the TP. This is the situation with Rogo, for example, as a student who is allowed to access Rogo should not necessarily be allowed to access every paper within Rogo. Therefore, the Rogo team at the University of Nottingham have implemented LTI in such a way that it is necessary for Rogo to contain it’s own user information. When a user first accesses Rogo through LTI, they must login separately to Rogo. Rogo then stores a link between the user_id passed through in the LTI launch data (which, in combination with the oauth_consumer_key, uniquely identifies the user) and the user within the Rogo system. Thereafter that user should never again need to login to Rogo when coming in through LTI from the same TC.

An LTI link to Rogo only provides a user with access to a single paper. In order to define which paper is linked, the first time an administrator/module convenor (as defined in Rogo) accesses the LTI link (which should be when the link is set up in the TC), they choose the paper from the list of papers for which they are an editor. Thereafter, students coming in through this LTI link will only be able to access that paper (and then only if they are allowed to access that paper within the Rogo system, i.e. they are a member of the module to which the paper belongs).

The situation with Rogo causes problems for us, as we want our students to be able to login using the University of Oxford single-sign-on system (which is used to login to Weblearn), and not need a separate set of login details for Rogo, even if they only need them for their first login. Therefore, we are looking into logging users into Rogo directly through the single-sign-on system, rather than using LTI.

For iCases, we do not want to have to pre-register all users within the system, as is necessary in Rogo. Unlike in Rogo, we are planning only allow access through LTI. We will then create a user profile when a user first accesses the system and this user profile will be linked to the LTI user_id/oauth_consumer_key. WebLearn passes through sufficient information (email address, name, and hopefully single-sign-on username) that we can know who a student is based on this LTI launch data, so we can monitor students’ activity and performance. This information is not required under the LTI specification, but we will make other institutions who use iCases aware that in order to track students’ activity and performance, their TC will need to provide this information, otherwise they will need to find out who a user is based on the user_id passed through in the launch data.

An LTI link to iCases will only allow a student access to a single iCase. If a user wants to access a different scenario, they will have to come in via a different LTI link, with the appropriate resource_link_id. We would prefer not to maintain a list of user/scenario associations, which would enable users to access multiple scenarios through a single link. However, we are still in the early stages of implementing LTI for iCases, and it may be something we choose to do further down the line.

 

Posted on

Personalising WebLearn (Sakai) – The BMS Portal page

This year (2011-12), a new course, Biomedical Sciences, started within the Medical Sciences Division. This course combines  teaching specific to the course with teaching shared with other courses. In response to this, we wanted to ensure that the students’ experience of the course in WebLearn (Oxford’s Sakai-based VLE) was coherent and personalised, and didn’t require them to search through different parts of WebLearn to find what they needed.

Therefore, we decided to create a portal page that makes it easy for students to access the information – timetables, documents, etc – relevant to them. We wanted the page, and all of the content, to remain in WebLearn, to ensure that managing the content and the users remained straightforward for lecturers and administrators accustomed to using WebLearn.

Biomedical Sciences Portal Page
The Biomedical Sciences Portal Page (click to enlarge)

The resulting portal page, shown above, provided students with a slick, modern-looking page, on which they could see any recent announcements, view their timetable and access documents both relating to their course and from their personal site within WebLearn.

In order to achieve this, it was necessary to create a multi-level structure for the site, with the main site containing a subsite for each year of the course, and each year site containing a subsite for each module.

To dip quickly into the technical aspects, the portal page makes significant use of JavaScript, in particular the JQuery library. Where possible, the content, along with the user’s status and year-group, is gathered using Ajax requests to ‘WebLearn direct’ URLs, which return information, such as a user’s recent announcements, in a computer-friendly format, e.g. JSON. A brief summary of how the different sections of the page are created is given below:

Announcements

WebLearn’s direct methods are used to get a user’s announcements, specifying the number and age to show. These are then presented to the user in an ‘accordion’, where clicking on an announcement title expands further details of that announcement.

Calendar

The requirement for the calendar was to bring together multiple module calendars into a single view, with a different colour for each module. This was achieved as follows:

  • The calendars for each module reside in the module sites.
  • A Google account is subscribed to the calendar (ICS) feed provided by WebLearn for each module.
  • A Google-calendar view of all the module calendars, with each one assigned a different colour, is embedded into the page.
  • In order to combine the multiple feeds back into a single ICS feed that students could sign up to, e.g. on a smart phone, we used a tool called MashiCal.  However, requires manual input of the feeds to be ‘mashed’ – this has not been a problem so far as the students all do the same module in Year 1.

Course Docs

Documents and resources are held in the subsites for each year/module, with some general resources in the top level site. At the time of creating the portal page, there were no direct methods for accessing resources, so a somewhat clunkier method was used. The portal page requests the web view (an HTML page) of the appropriate resources and then uses JQuery to dig down through the folder structure to extract the links to all of the resources and present them in a tree view.

My Stuff

This provides a view of everything in a student’s My Workspace resources folder, produced in the same way as the Course Docs. Students can only view their resources from the portal page – they have to actually go to their workspace to upload/edit resources.

Future Developments

  • Access resources for Course Docs and My Stuff using direct methods (now available after a recent upgrade), as the current process of extracting links from HTML pages is slow and error-prone.
  • Extending functionality of My Stuff, in particular enabling drag-and-drop upload of files, so students can quickly upload files from any computer, e.g. results in the lab.
  • Creation of our own  ‘calendar aggregator’, to automatically combine ICS feeds for each student based on the modules they are studying.