Message always appears when launching via Canvas into a new window/tab

[dsobiera]

When launching tools from Canvas into a new window/tab the message - "Timeout handling LTI authentication (storage), redirecting anyway." always appears. This is from people using desktop browsers. It does eventually redirect to the correct place and all works as expected but our user base is complaining about that message like it is an error that needs to be reported.

Is this normal for this message to appear on new tab launches? If not, is there some configuration piece on our end that is lacking? Any way to not show this message?

Thanks!

[buckett]

@dsobiera This isn't expected, but it's possible. We try to use session storage to get around cookie blocking for iframes, but suspect it's not working correctly when the tool is launched in a new window. If you have worked out a good solution we're all open to pull requests.

[maurercw]

I'm not 100% sure that the session storage is working for a normal launch, but it for sure isn't when launching in a new window. I added some debugging to your javascript for the step 1 side (lti.put_data):

// Validate it's the response type you expect
if (event.data.subject !== message.subject+ ".response") {
    console.log("(Step 1) Not the right response type. Expected: " + message.subject + ".response; got: " + event.data.subject)
    return;
}

And am getting this:

(Step 1) Not the right response type. Expected: lti.put_data.response; got: lti.put_data

So I don't know if this is behavior that changed from Canvas, or an expectation in your code that is wrong. Canvas's documentation is a bit sketchy here, and says that things "should" come back with a .response.

[buckett]

I've got a PR out for this ( #53 ), basically it looks like it's not possible to use postMessage to store the state when launching in a new tab/window as there's no reference available to the JavaScript to the window which messages can be sent. window.opener is null as Canvas doesn't do the LTI launch directly to the tool so browsers seem to block access to the window.opener property. I'll try and get this reviewed and released soon.

[buckett]

This should be fixed in 0.3.3 (or worked around assuming the client has cookies available in the popup).