1.5 KiB
Consistency in error management
Both exceptions and error reponses are used. A choice should be made between the two options. A combinaison of both is fine as long as the logic is comprehensively documented.
Response::Error class is overused. A simple error message is given instead of specific messages for each recurring error. In the same time, some exceptions (such as AdminAuthenticationException) are used a few times for the same kind of errors.
Requests work mostly on current user, but some take a UserID to identify another user. Requests should either always work on current user (which implies to create new requests working on another user) or always take an optional UserID parameter.
Authorization rules
Logged users can:
- retrieve public data of any user individually
- change their own data: password, email address, profile entries (except the read-only ones)
- delete their account
Admins with 'Read' permission on the '*' resource can:
- list users
Admins with 'Edit' permission on the '*' resource can:
- change data of another user
Admins with 'Admin' permission on the '*' resource (or the 'admin' boolean) can:
- change read-only profile entries and permissions
- delete a user
- uprank and downrank admins
Structures, not classes
Maybe in some cases, it could be great to use structures instead of classes. They are simpler, use less memory and computation.
CLI client
Current client authc lacks most requests.
Documentation
Documentation isn't started, yet. TODO!