Closed (fixed)
Project:
LTI Tool Provider
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
30 Nov 2012 at 18:12 UTC
Updated:
19 Dec 2012 at 21:50 UTC
Safari 5.1.4 + (http://support.apple.com/kb/HT5190) and IE (without a valid P3P policy) will not allow an iframed application from a different domain to set a cookie.
The lti_tool_provider module will often provide Drupal content meant to be iframed within an LMS. In this case, we should help the user out a bit instead of session-setting failing.
One potential would be to help the user break out of the iframe into a separate browser window.
Comments
Comment #1
jzornig commentedI thought that there was an exception to this rule for iframed applications launched with a POST. The LTI launch is an OAuth POST request.
If the browser is not accepting cookies then the Drupal site can not detect this until the second page request which will not include the OAuth POST data.
Most LMS should have an option to configure LTI links to launch in a separate window. Otherwise you could enable URL based sessions in your Drupal site.
Comment #2
jzornig commentedI just tested with safari, firefox, chrome on mac and IE on windows with the consumer and provider on different domains and the provider launched in an iframe, with no issues. Are you sure you are not having a different issue.
Comment #3
samo commented> and the provider launched in an iframe, with no issues.
Did you test maintaining the session after the provider launch? The problem with Safari and IE is that the session cookie can not be set, so the launch works just fine but no deep clicks work as the session is not maintained.
Comment #4
jzornig commentedI did manage to get IE to prevent cookies. In my prior testing IE was treating our provider site as Intranet and allowing cookies. I've added a note in the README.txt on adding a p3p header in the settings.php which satisfies IEs default configuration and allows cookies when the tool is in an iframe.
In the future I might look at additional measures, but currently I'd classify handling enabling cookies in the users browser as the responsibility of the integrator and not of the module.
Comment #5
jzornig commentedComment #6
samo commentedWell, it's easy for you and I because we know about the issue.... I was hoping we could save new integrators from hours of trying to figure out why this module does not work for them inside an LMS with Safari.
Comment #7
jzornig commentedUnfortunately the diagnosis occurs before the cure so if I add the diagnosis the cure never gets a chance to work.
Diagnosis: I can tell from the headers on the launch POST that the browser will not allow P3P cookies, and as a response direct the user to a message to that effect.
Cure: By adding the P3P header in the settings.php file, the browser will make an exception and allow cookies when it receives the response to the launch POST.
The usual pattern of interaction between a browser and web site goes:
GET request ->
<- login form response (set a test cookie, and include p3p header)
POST request -> (if cookies allowed will include the test cookie)
<- landing page response or error page cookies not supported
With LTI launch we have
POST request ->
<- landing page (set a session cookie, include p3p header)
The only ways I can see to get around this are to insert a process where we do a browser redirect to an auto submit form between the POST and the landing page response. Or include a javascript in the landing page that tests for cookies on the browser side. Both of these depend on javascript.