The logic about missing tokens implying logged in users (and that
all logged in users have access to any method protected by a token
capability) is correct. However, I believe it is both confusing and
brittle, and leaves a security-related door ajar for future foot-gun
incidents.
Instead, apply Abilities as normal, and keep the Capabilities
involvement only for situations where a token is provided. This
reduces the cognitive burden when considering Abilities in isolation.
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
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
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
This avoids passing around the reported_user via forms. There was no
validation anywhere that the reported_user corresponded to the object
being reported. This approach removes those worries too.
