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.