search

hypothesis / support-legacy

a place for tracking support-related work and projects
3 stars 0 forks source link

"401 Unauthorized Secure URL hash mismatch" error in Canvas assignment #174

Closed mattdricker closed 3 years ago

mattdricker commented 3 years ago

A URL assignment created in our Canvas instance will open fine in Chrome, but if the assignment is opened in Firefox or Safari the page displays "401 Unauthorized Secure URL hash mismatch" error.

To Reproduce

  1. In Chrome, view the original assignment here: https://hypothesis.instructure.com/courses/92/assignments/1490
  2. Open same assignment in Firefox or Safari

The above assignment was created using Chrome several hours earlier in the day before I discovered this. I've since set up a number of different scenarios to test:

Created new assignments in each browser using same source webpage as above (URL for page and originating browser in the assignment title):

All above assignments open fine in Chrome, error in Safari & FF

Created new assignments in each browser using new source webpage:

All above assignments open fine in all browsers.

Created new assignment in Safari using new source webpage with parentheses in URL:

This assignment throws the 401 error when opened in Safari. However it opens fine in Chrome and FF.

MacOS 11.2.1 Chrome 88, Safari 14.03, Firefox 84

mattdricker commented 3 years ago

Just went back to test everything again, and all assignments are now loading fine in all browsers.

To amend, I'm seeing intermittent successful loading, and intermittent errors, as documented above.

mkdir-washington-edu commented 3 years ago

https://app.hubspot.com/contacts/6291320/ticket/312189645

I initially thought this error was from an incorrect LMS role, as changing the role (user had the role of "Staff" instead of "Faculty") fixed the issue. However, it appears that this was really the intermittency of the error. The user reported seeing the problem again, so I've asked them to try Chrome.

They reported the issue after creating an assignment using https://facultyinnovate.utexas.edu/news/plus-one-thinking-framework-inclusive-teaching in BB Ultra using FF 85.

robertknight commented 3 years ago

Using https://hypothesis.instructure.com/courses/92/assignments/1490 I can indeed reproduce the issue in Safari 14 and Firefox 85 whereas in Chrome it loads successfully.

robertknight commented 3 years ago

FYI - we're temporarily turning authentication off in prod until this is resolved. See https://hypothes-is.slack.com/archives/C4K6M7P5E/p1614170783094000?thread_ts=1614170538.092800&cid=C4K6M7P5E. We're leaving it enabled in QA so we should be able to reproduce it there.

robertknight commented 3 years ago

Some debugging notes:

The immediate cause of the problem is that when ViaHTML checks the signature in a signed URL, in the via.sec query param, the URL that it computes the signature for is not the same as the URL that was signed.

ViaHTML gets the URL of the request using WSGI's get_current_url function. This function uses a url_quote helper to reconstruct the path from the PATH_INFO key in the HTTP environ. This will percent-encode characters such as '(' and ')' (present in the Wikipedia article URL above) which might not have been encoded when the URL was signed.

For example, if the following request is made to ViaHTML running locally:

curl http://localhost:9085/proxy/http://en.wikipedia.org/foo(bar)

Then the WSGI HTTP environ contains:

{
'QUERY_STRING': '', 
'REQUEST_METHOD': 'GET',
'REQUEST_URI': '/proxy/http://en.wikipedia.org/foo(bar)',
'PATH_INFO': '/proxy/http://en.wikipedia.org/foo(bar)',
...
}

But wsgi.get_current_url(http_environ) returns:

http://localhost:9085/proxy/http://en.wikipedia.org/foo%28bar%29
robertknight commented 3 years ago

We have implemented a new method of allowing requests from the LMS to ViaHTML which bypasses the URL signature problem here: https://github.com/hypothesis/viahtml/pull/87. This has now been deployed to production. Details here: https://hypothes-is.slack.com/archives/C0C6BDS1H/p1614258716014000.

I still intend to fix the URL signature problem in case we find that the new mechanism is needed in future. If however we can get by with just the referrer-based authentication then that has the advantage that it is simpler to configure and debug.

robertknight commented 3 years ago

Change of plan: We're intending to remove the URL signature checking from ViaHTML rather than fixing it, since the Referrer-based checking is good enough on its own. See notes and links in https://github.com/hypothesis/viahtml/pull/88.