<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/6/20 5:07 PM, Cantor, Scott wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CY4PR0101MB3096D1BFBC643E07B0405935D01D0@CY4PR0101MB3096.prod.exchangelabs.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Currently this shows that ServiceNow and Instructure have apparently now
been fixed by the vendors;
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Allowing that it may be rolling out to tenants, I can say that OSUs Canvas instance is not fixed. Last I spoke to people here, they were denying responsibility, but that was Tier 1 support and I suspect their developers are working on it.</pre>
</blockquote>
<br>
I just retested Georgetown's Canvas. It does now seem to be working
correctly with Chrome 80 on my MacOS 10.14.6 desktop + the 2
SameSite flags enabled, even when launched with
--enable-features=SameSiteDefaultChecksMethodRigorously, to disable
the 2 minute grace window for the "Lax+POST" case. A ps confirms it
is effectively running with all 3 flags set:<br>
<br>
--enable-features=CookiesWithoutSameSiteMustBeSecure,SameSiteByDefaultCookies,SameSiteDefaultChecksMethodRigorously<br>
<br>
<p>Curiously though, it still seems broken under Firefox with the
two similar SameSite-related options set in <a class="moz-txt-link-freetext" href="about:config">about:config</a>. The
failure is that you seem to get in, but the URL you wind up in
Canvas is "/?login_success=1"; that query param is not typical.
Then when you click on a course in the Dashboard (or attempt to
directly go to a course URL), it winds up redirecting you back to
the IdP and you wind up back in the Canvas Dashboard in the same
state. So you can't actually get into anything beyond the initial
Dashboard page.</p>
<p>So not sure what to make of that. Seems like Chrome and FF's
behavior have diverged. And so not entirely clear to me whether
Chrome is really truly working here - and will continue to work
when Chrome is settled into its final default state - vs is there
some issue with the testing methodology that is off (e.g.
SameSiteDefaultChecksMethodRigorously isn't doing what it claims).<br>
</p>
<br>
</body>
</html>