UDOIT
UDOIT copied to clipboard
ucfopen
ID not received from Canvas in Safari
This screen appears when I try to view UDOIT 3.1.1 in Safari 15.1. It works fine on the same computer in Chrome.
UDOIT 3 was designed to use cookieless sessions, so it shouldn't be affected by how strict Safari is with third-party cookies. @cidilabs Have you had a chance to investigate this issue?
We haven't looked into it yet. Since we're using DB sessions and not cookies, my initial thought is that it sounds more like the POST variables aren't coming through. But I've never heard of POST variables being blocked in an iframe, even with strict security.
The Safari user should be able to determine the issue. Here is helpful debug info:
https://auth0.com/docs/troubleshoot/troubleshoot-authentication/renew-tokens-when-using-safari
I now get the same issue in Firefox 96.0.1 on the dev branch. Chrome seems to work for now
Firefox 96 changelog has this:
Firefox will now default all cookies to having a SameSite=lax attribute which helps defend against Cross-Site Request Forgery (CSRF) attacks.
and I do get a warning about this in the console.
Does Firefox tell you what cookie is being blocked or modified (SameSite=lax)?
Some cookies are misusing the “SameSite“ attribute, so it won’t work as expected 6
Cookie “_csrf_token” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. 10
Cookie “log_session_id” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. 10
Cookie “_csrf_token” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. unread_count
Cookie “log_session_id” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. unread_count
Cookie “_csrf_token” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. unread_count
Cookie “log_session_id” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute. unread_count
I'm not seeing any CSRF cookies set from UDOIT. Do you have to do something to turn this on?
It looks commented out https://github.com/ucfopen/UDOIT/blob/d19ef66a7fd70d45f85d17b1ba1ec6e4c3a64f65/config/packages/framework.yaml#L3
Thought this commit changed some things. https://github.com/ucfopen/UDOIT/commit/9e1220610c10553d790a786cfd2a38ea91f1c653#diff-f9e152e493ceb9869882553ec779d78fb91a57bf34ca5195ab015d2befec0f8f
I wonder if this "none" is case sensitive and needs to be "None"?
I don't believe I'm using any special configuration. I also realized that those warnings happen just in regular canvas, so this is probably not related to this issue.
Version info: confirmed working on Firefox 95.0.2, confirmed not working on Firefox 96.0.1
I'm not sure what I'm doing differently, but I just tested in Safari and Firefox 96.0.2, and it authenticated just fine for me in both. Very strange.
Will someone who is having this issue share the POST variables Canvas is sending?
Working in Firefox 96.0.1 with POST variables as follows:
iss | "https://canvas.instructure.com"
login_hint | <short encoded value>
client_id | "10000000000014"
target_link_uri | "<my udoit testing instance>/dashboard"
lti_message_hint | <very long encoded value>
canvas_region | "not_configured"
Strangely enough; it seems to be working fine in Firefox 96.0.2 as well for me now. However, Safari still doesn't work.
It has these variables if I'm reading them correctly.
client_id | 10000000000014
login_hint | <short encoded value>
lti_message_hint | <long encoded value>
nonce | nonce
prompt | none
redirect_uri | https%3A%2F%2Fudoit-rob.herokuapp.com%2Flti%2Fauthorize%2Fcheck
response_mode | form_post
response_type | id_token
scope | openid
state | <UUID looking string>
Interestingly enough, there's no iss in this one.
My best guess is that it is related to the fact that canvas seems to attempt to add these parameters by using a <form> with method="POST" and a bunch of <input type="hidden">s. The iss parameter does appear as one of these <input type="hidden">s in the HTML, just like in Firefox in Chrome, but Safari doesn't seem to pick it up for whatever reason.
It seems like your comparison from Firefox to Safari is comparing two different parts of the LTI 1.3 initiation cycle.
What's the hypothesis with hidden variables? Is there any indication of browsers changing behavior here?
Cookies still seem like most likely cause. I know it was said that cookies aren't being used, but this doesn't seem completely accurate. I see cookies for the session and for redirects (sf_redirect).
That's an interesting point. The system was designed to not be dependent on cookies. However, that's not to say that somewhere in implementation one of the components we're using didn't add a dependency on cookies behind the scenes. For example, the sf_redirect cookie you mentioned is one I've never seen. I'm wondering if the SF is "symfony framework". We'll need to do more research on that.
The system was designed to not be dependent on cookies.
I assume this means transferring session state back to the LMS with an auth token and then receiving it back.
I'm wondering if the SF is "symfony framework".
Yup, good instinct: https://github.com/symfony/symfony/blob/bf2fb938be7ef03339976b12db76aa1b1e59aa97/src/Symfony/Component/HttpKernel/DataCollector/RequestDataCollector.php#L147-L160
I did some more poking around in this issue, and discovered some interesting information.
The direct cause of the failure is the POST to /lti/authorize/check, which sends error: login_required and error_description: Must have an active user session in the POST body instead of id_token. This causes the error page that UDOIT sends back.
However, the way this POST is sent is via a <form> with <input type="hidden">s and one line of JS: document.getElementById('authorization_redirect_form').submit();. This code's source appears to be the response to the original POST to /lti/authorize. In Firefox, it has id_token, in Safari, it has the errors mentioned above.
I looked at the POST to /lti/authorize, and I couldn't find anything apparently different between Firefox and Safari. To clear up any confusion, I was wrong, iss is present across both browsers; I just don't know how to read Safari devtools. Something must be going wrong during the initial POST to /lti/authorize in Safari, but I'm not sure what.
Great, this will help us get to the bottom of the issue. Thanks!
On Thu, Jan 27, 2022 at 12:53 PM Robert Boyd III @.***> wrote:
I did some more poking around in this issue, and discovered some interesting information.
The direct cause of the failure is the POST to /lti/authorize/check, which sends error: login_required and error_description: Must have an active user session in the POST body instead of id_token. This causes the error page that UDOIT sends back.
However, the way this POST is sent is via a
-- Chuck Crandall
(801) 888-4985 Join us on Slack! https://cidilabs.com/slack-invite/ And check out our webinar series https://cidilabs.com/webinars/
Oh I remember this one.
It looks like to reproduce this you have to have "Prevent Cross Site Tracking" checked which I believe is the default in Safari. I didn't have this checked as many LTI services don't work with this checked. I don't think there is currently a solution for instructure.com hosted domains with the current version of LTI besides launching the tool in a new window. Kaltura's recommendation was "We suggest transitioning your environment to be hosted on your own domain so you would be able to create a sub-domain." :/ I believe there is an LTI spec in discussion for changing the launch from using cookies.
If you have a vanity domain and host UDOIT on a subdomain as part of that this is not a problem. For instance we have https://canvas-test.it.umich.edu/ as our test instance and it works. But it doesn't with umich.instructure.com.
Also some libraries like the Python PYLTI13 do his check and display this message in Safari if it has this option checked. Not ideal but at least it works around this option. Most of our local tools use Python and this library so is probably why we haven't heard too many complaints about this.
