Monthly Archives: March 2013

LTI, Frames and Cookies – Oh MY!

I got the following question about LTI recently:

Recent Safari and Chrome browser versions have changed the way they filter 3rd party
cookies in iframes:

http://stackoverflow.com/questions/9930671/safari-3rd-party-cookie-iframe-trick-no-longer-working
http://groups.google.com/a/chromium.org/group/chromium-discuss/browse_thread/thread/91fb1bf55e483dc4

Previously, a POST in an iframe would allow the target of the POST to set cookies. However, this has changed, and those cookies are no longer allowed when 3rd party cookie blocking is enabled (the default setting). This causes them to completely break Basic LTI tools that use cookies to establish and maintain a session and all of the LMS systems enclose LTI Tools in an iframe.

Here is my Answer

The simple answer is that tools will need to go through a step where they attempt to set a cookie and then do a redirect back to themselves with the session as a GET parameter and check to see if the cookie is set. If the cookie is not set – they should open in a new window, passing the session id as a GET parameter and then setting the cookie and redirecting to one’s self one more time.

Yes – it sucks. And many tools just give up and don’t even bother trying to set a cookie within frame. If they notice that they are not the top frame pop open a new window with a GET parameter. Friendly instructors or admins placing the tool could make it easier and just tell the lMS to pop up in a new window. But the tools shold not assume this is the case and gently deal with being in an iframe or new window.

I think that in the future there will be two situations. (A) Relatively large tools that insist on a new window and immediately pop themselves out into a new window if they find themselves in an iframe. (B) Small widgets that happily live in an iframe but do not use any cookies at all to maintain session – they just use GET parameters or POST parameters on every screen to maintain the session state.

How to Build a Rich / Non-Trivial IMS LTI 1.1 Provider

PHP IMS LTI 1.1 Providers

I have a “hello world” provider in PHP here:

https://source.sakaiproject.org/svn//basiclti/trunk/basiclti-docs/resources/docs/sakai-api-test/tool.php

It is nice as it does all of LTI 1.1 as well as Sakai’s extensions documented here:

https://source.sakaiproject.org/svn//basiclti/trunk/basiclti-docs/resources/docs/sakai_basiclti_api.doc

I have built a few other PHP providers that do a little more and use a database with some Authz and different implementation approaches. I used these as examples for various advanced LTI workshops I have given:

http://ims-dev.googlecode.com/svn/trunk/basiclti/php-simple/adlist/
http://ims-dev.googlecode.com/svn/trunk/lti/lms/

The best example is the Moodle LTI 1.1 Provider written by Juan Levya. The Moodle provider is more rich and powerful than the Sakai provider (below). The Moodle provider does grade send-back as well launch and provisioning at either a course or a tool level. I would love to get Sakai’s provider to feature parity with Moodle’s provider.

http://docs.moodle.org/22/en/LTI_Provider
https://moodle.org/plugins/view.php?plugin=local_ltiprovider

https://github.com/jleyva/moodle-local_ltiprovider

Java IMS LTI 1.1. Providers

There are three samples of Java LTI code here:

http://ims-dev.googlecode.com/svn/trunk/basiclti/

They were the initial sample code that was developed as proof-of concept. The Sakai LTI 1.1. providers started with this:

http://ims-dev.googlecode.com/svn/trunk/basiclti/java-servlet/

And went quite a ways beyond it. So I would ignore the above and start with:

https://source.sakaiproject.org/svn/basiclti/trunk/basiclti-portlet/src/java/org/sakaiproject/blti/ProviderServlet.java

https://source.sakaiproject.org/svn/basiclti/trunk/basiclti-docs/resources/docs/sakai_basiclti_provider.doc

You will note that the code here:

https://source.sakaiproject.org/svn/basiclti/trunk/basiclti-util/src/java/

Is not even copyright Sakai – it is generic utility code copyright IMS and others – and it is more well-tested than the code in http://ims-dev.googlecode.com/svn/trunk/basiclti/java-servlet/ – so I would start with this as your utility code.

The connection between that generic Util code and Sakai APIs happens here:

https://source.sakaiproject.org/svn/basiclti/trunk/basiclti-common/src/java/org/sakaiproject/basiclti/util/SakaiBLTIUtil.java

I made sure that I kept the generic bits and non-generic bits 100% separate.

Sakai LTI 1.1 Beta Release – 2.1.0-b01

I have been working on a new release of the Sakai LTI support to complete the support for IMS LTI 1.1 and lay the ground work for an effort to implement IMS LTI 2.0 in the summer. The internel Sakai version number for the LTI code base is 2.1.0 (unrelated to the IMS spec version number).

This code is planned to be shipped with the Sakai 2.9.2 release – sometime in May or June. It will likely be the version that is installed by many Sakai schools over the summer.

Many things have been fixed, new features have been added, the UI has been cleaned up, and there are several security fixes.

Release notes including the 40+ JIRA tags fixed in the 2.1.0 release:

https://confluence.sakaiproject.org/display/LTI/LTI+-+Release+2.1.0+Notes

Video demonstration:

http://www.youtube.com/watch?v=Xfmc6ePgyaw

Beta 01 Tag:

https://source.sakaiproject.org/svn/basiclti/tags/basiclti-2.1.0-b01/

It would be great if folks were willing to test this and give me some feedback.