Cookie from Production Server Doesn't Get Sent Properly on HTTPS

[craig-riecke]

I have an CACCL 2.0.5-backed LTI app that works fine on the dev server. In installed it on a cloud server on Kubernetes where it runs in pure HTTP mode on port 8080. A load balancer sits in front of it and terminates TLS there.

When Canvas calls the /canvas/launch URI, the browser gets a Set-Cookie for CACCL_Canvas_app and a session cookie, but that cookie is marked HttpOnly. Thus the browser, on subsequent requests, knowing it's going to an HTTPS URL, doesn't send the cookie. Therefore the LTI thinks that someone is trying to run it's being run outside of Canvas and barfs.

I'm looking through the code to see where the cookie sent back, but I haven't found it yet.

[buckett]

I'm not sure it's related to the HttpOnly flag on the cookie as that prevents JS from accessing the cookie but will still allow it to be sent on HTTPS and HTTP requests (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies).

Could it be that the browser is blocking the cookie being sent on the subsequent requests because it is considering the LTI tool running in the iframe to be 3rd party content and it's more strict about what cookies it will send in that context?

[gabeabrams]

We’re tracking this issue and most often, it seems to come down to the fact that many browsers no longer allow 3rd party sites to have cookies within iframes. We’ve fixed this in one of two ways: use a domain that matches the specific canvas instance (if canvas is canvas.Harvard.edu then the app should be myapp.canvas.Harvard.edu or something), OR we just have the app open in a new tab. Honestly, that’s the option we usually go with (app in a new tab).

[gabeabrams]

(@buckett, I’m pretty confident that your second paragraph explains what’s happening here)