iCases freely and publicly available!

iCases are action mazes on the web which deliver complex and engaging learning. They have been used in the Medical Sciences Division for the last few years, and have been very well received by students.

iCases give students the opportunity to interact with experimental data in a realistic context. For example, with limited time and money, students must decide what tests are needed to resolve a complex situation typical in biomedical sciences. Research is needed before students can begin the case, background information and references are provided. A simple quiz is used to show that they are ready to proceed to the case itself.

Find out more about iCases

Use iCases NOW!

The following iCases are now freely and publicly available, supported by the HEA Bioscience OER project:

Please note that your attempts at these iCases, and any written answers you enter, will be available for anyone else to see.

 Interested in Using iCases in your Institution?

The above iCases are freely available for use under the specified license. If you wish to have individual accounts for your users (so that an individual will only be able to see their own attempts/answers), there are two options available:

  • iCases is a LTI Tool Provider, and so can be integrated into any VLE/LMS that conforms to the LTI standard. User access will then be controlled by the VLE/LMS.
  • We can, on a limited basis depending on demand, provide accounts within WebLearn (the University of Oxford’s VLE) for use by your users.

If you wish to discuss either of these options further, please contact MSD Learning Technologies.

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.imsu.ox.ac.uk/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!

Resetting the root password/privileges for MySQL/PHPMyAdmin (XAMPP 1.7.3, MySQL 5.1.41)

We use XAMPP for our local development (on Windows), and I have a habit of messing around with the database and doing bad things by mistake, because it’s only for local development, so it doesn’t matter that much. It’s still annoying when I lock myself out of all my databases though!

While setting up a wordpress site locally for testing, I managed to remove the global privileges of the root user in PHPMyAdmin, thinking it was the user for the wordpress database. I did the usual thing of searching for solutions online, and after trying a few different things involving the command line and MySQL Workbench, I came across this Apache Friends forum thread: http://www.apachefriends.org/f/viewtopic.php?f=16&t=46832. The instructions boil down to the following:

  • Open mysql/resetroot.bat in a text editor
  • Add “–datadir=c:/xampp/mysql/data” into the “mysql\bin\mysqld.exe…” line (line 18), after “–no-defaults”. Change the datadir parameter to the path to your data directory – the one shown is the default.
  • Run resetroot.bat – this should reset the MySQL root password and privileges. You can then login to MySQL/PHPMyAdmin using the username root and no password. For security, you should set a password for the MySQL admin user in the XAMPP Security panel: http://localhost/security/

CakePHP Session data being lost on redirect

Having successfully enabled access using LTI to a local version of iCases – see https://learntech.imsu.ox.ac.uk/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.