This will work alongside T161890.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | jsn.sherman | T147434 Version 1.5: Beta fixes | |||
| Resolved | • Samwalton9-WMF | T151177 Migrate users from signup sheets to the Library Card Platform | |||
| Resolved | jsn.sherman | T163670 If not logged in, users clicking a link they're not allowed to view should be asked to log in | |||
| Invalid | jsn.sherman | T158800 Improve error handling for disallowed users | |||
| Resolved | jsn.sherman | T167194 Split authentication and authorization errors |
Event Timeline
Comment Actions
Primarily because this task would solve T163670, I'm adding this to the list of tasks to be completed before user migration.
Comment Actions
This is ~ 65% complete in theory and ~ 90% complete in practice, with the current enhancements deployed to staging. Will comment on the various tasks this touches.
Comment Actions
Discovered that generating user-friendly 401 (authentication) error pages in django is more difficult than 403 (authorization) error pages. So we're still using the 403 page in places that I would prefer to use a 401.
By completing T163670 (on staging), there are basically no conditions under which a person will encounter an error page due to them not being logged in, rather they will be redirected to the oauth login process.
I have added contextual messages in every place that we're raising a 403 error that will let the user know the nature of the problem, including if it's an authorization problem. These messages may stack with other messages. I've attached an example screenshot of my non-coordinator account attempting to access a url for evaluating an application that I shouldn't be able to view.
Comment Actions
Picked up a few danglers that use the django builtin "is_staff" test, which works a bit differently from other permissions. I'd call this totally done on staging, and ready to push to prod unless there are objections.