search

openequella / openEQUELLA

Core openEQUELLA sources
https://openequella.github.io/
Apache License 2.0
41 stars 44 forks source link

SameSite policy change in Google Chrome will break the LTI integration (and maybe others) #1458

Closed ddelblanco closed 3 years ago

ddelblanco commented 4 years ago

In February of 2020 Google will release version 80 of its Chrome browser. A change to the default cookie behavior will potentially cause LTI Tools that rely on cookies to have problems embedding inside Tool Platforms. Other browsers are likely to implement these default changes in the future.

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

It will be required to configure the cookies to have SameSite=None and Secure settings.

But, not all browsers treat the SameSite=None setting in the same way, so we may need to tailor our solution to handle both cases. See: https://web.dev/samesite-cookies-explained/

To Reproduce Steps to reproduce the behavior: To test the effect of the new Chrome behavior go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. Then try to access with LTI to Equella from an LMS. The cookie is rejected and the login page is shown.

Expected behavior The cookie should be marked as SameSite=None and Secure, and then Chrome will let the LTI call to continue.

Platform:

Additional context These link can help too: https://community.canvaslms.com/docs/DOC-18313-samesite-cookies-and-canvas

edalex-ian commented 4 years ago

I wonder if we'll need to be somewhat selective with this too. That is, should we potentially use None for the selection sessions, but Lax when simply viewing items/attachments which have been included in an item. Thoughts?

(Actually, we may even be fine with Strict for viewing. :thinking: )

cbeach47 commented 4 years ago

Default settings in Chrome 80 allow at least the Canvas <> oEQ 2019.1 integration to work as-is for now, so unless an adopter's IT policy is to change it, this appears to not be a critical issue, but should be addressed soon.

Another flow to consider is launching the File Manager or In Place File Editor - setting the cookie to be httpOnly and secure breaks the applets by not authenticating the user inside the applet code. Admin Console seemed to work OK in that scenario.

Overall, I like the idea of having cookies' SameSite change based on use. I am flagging this for the CDM.

mrblippy commented 4 years ago

I came across this issue while using the moodle/oEQ lti integration. The user is presented with an oEQ login screen.

As soon as the 'SameSite by default cookies' flag is disabled (via chrome://flags/) the integration works correctly again

nelson-edalex commented 4 years ago

A workaround I found is to edit the oEQ cookie on your reverse-proxy to change the cookie into SameSite=None. For example on Apache reverse proxy, add this rule,

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=None

Reload Apache and then clear your browser's cookie. This works with oEQ-Moodle integration on Chrome, FF, MS Edge and IE11

cbeach47 commented 4 years ago

Confirmed this fixes the Canvas and Blackboard LTI integrations in Chrome.

Confirmed it works in FF (no effective difference).

My Bb test site's (v3800) oEQ B2 is broken (something about it not having a content handler / placement) - so I didn't test this with the B2 LTI flow.