Kolibri: errors when trying to explore without an account

[indirectlylit]

Observed behavior

Reported by @jonboiser, @jayoshih, @jtamiace, @radinamatic

• https://www.notion.so/learningequality/Get-the-401-error-pop-up-after-clicking-Explore-without-account-1a40ad6d83af4d089c0c009958ae98a8
• https://www.notion.so/learningequality/Got-403s-when-I-tried-to-explore-without-an-account-84d10b3edb2c43ba80ad83d41c7960ca

However I can not reproduce on the Kolibri beta server

Context

0.14.0 beta 3

[micahscopes]

I've managed to reproduce this and am working on it now.

The authorization popup only appears if I navigate to /en/learn/#/classes in an incognito window. It's because in the incognito window, I've not authenticated to the /learn/api/learnerclassroom endpoint, which returns a 401 response with a www-authenticate header (as required by the standard). The browser sees the 401 + www-authenticate header and decides to show a popup.

The two ways to solve this would be:

• send a 403/forbidden response instead
• don't send www-authenticate headers (a common hack)

[micahscopes]

Ooh, I've found a third possibility, which is to send a X-Requested-With: XMLHttpRequest header with the request, which should suppress the www-authenticate header in the response` (https://stackoverflow.com/a/20221330)

[jonboiser]

Users shouldn't be taken to the /learn/classes page when they click "Explore with an account" is that what's happening to you?

To avoid the situation where an unauthenticated user is going to /classes, we should be redirecting them away to the /learn/topics page like I want to do in #7154 (for authenticated users not part of any classes).

[rtibbles]

Yeah - this sounds like a follow on consequence of #7154, but also agree we should not be sending the www-authenticate header, as it's not relevant in this context.

[micahscopes]

When I click "Explore without an account", I'm directed to /learn/topics. So I guess I haven't reproduced the exact behavior described here.

That said, it seems that the 401 popup could be considered to be a secondary issue. Navigating to any page that makes a request to /learn/api/learnerclassroom will produce an authentication dialog because of the 401 response on /learn/api/learnerclassroom.

I tried sending X-Requested-With: XMLHttpRequest but [cherrypy ?] doesn't seem to respect the convention described here and still sends back www-authenticate headers.

[rtibbles]

@micahscopes is it returning a 401 or a 403?

[micahscopes]

@rtibbles It returns 401. It seems like 403 could be more appropriate, although I read some people saying that 403 is meant for situations where authentication is not suggested... where the resource is truly _forbidden_. Ideally we could just use that X-Requested-With: XMLHttpRequest convention to suppress the www-authenticate headers.

[rtibbles]

I think it's consistent with most of our endpoints to return 403 - alternatively, we could return a 404, which would be appropriately semantic, because an anonymous user has no classes and hence none are found.

[rtibbles]

Worth noting that 403s carry a particular significance for our frontend, as they will trigger a login in the frontend, whereas we do not currently do this for 401s - given the behaviour of Chrome and other browsers to 401 ajax calls - I am inclined to never used them.

[micahscopes]

Okay, so 403 would seem appropriate here.

[rtibbles]

I think so - and is consistent with our permissions elsewhere too.

[micahscopes]

I did some more digging and found that BasicAuthentication (the authentication class that returns 401 responses on unauthenticated requests) is actually disabled in production but not in development. When I disabled it in development, the login popups stopped.

@rtibbles can you help me understand why you kept BasicAuthentication as a default authentication class in development?

[rtibbles]

Mostly if people are using tools like POSTman to test API endpoints in development - it generally uses BasicAuth for authenticating the requests.

[micahscopes]

@rtibbles it doesn't seem super urgent, but it'd be nice if the popups didn't happen in development. So I made this PR: https://github.com/learningequality/kolibri/pull/7257

[micahscopes]

I changed the priority to P2, since the main issue reported here (the 401 popup issue) only happens with development settings.