Move to CanCanCan for authorization #2023
I've taken #1904, brought it up to date, and resolved a couple of things that I'd noticed and added a few more refactorings, including the first use of the
At this point, do we want to merge what we have already and then refactor the rest of the controllers in subsequent PRs, or should we wait until we're ready with a comprehensive PR that covers all controllers?
Access logic is not _entirely_ exported from the controller, unfortunately. For interface reasons, some actions which require admin have to be listed within the controller's deny_access method. This is required because, being a default-deny system, cancancan _cannot_ tell you the reason you were denied access; and so the "nice" feedback presenting next steps can't be gleaned from the exception
The OAuth capabilities are essentially user permissions that have been granted to the app. If the user authenticates through a non-oauth method, they are assumed to have granted all capabilities to the app
These are asking fundamentally different questions; Abilities are asking the application if the user has a role that allows the user to take a certain action Capabilities are asking if the user has granted the application to perform a certain type of action CanCanCan makes no distinction, however, so the `granted_capabilities` method is provided as a point that can be checked in rescue methods, so that one can _attempt_ to continue to provide the more informative error messages around permission refusals
tomhughes left a comment
I assume (given your question) that this can be used as is and the existing technology continues to work for unconverted methods?
If that is the case then I have no objection in principle to merging this and then proceeding with further refactoring separately.