2023-06-12 01:59:33 +02:00
### Consistency in error management
2023-06-11 21:10:03 +02:00
**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.
2023-06-12 01:54:34 +02:00
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.
2023-06-13 01:32:54 +02:00
### 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
2023-06-12 01:54:34 +02:00
2023-06-11 21:10:03 +02:00
### 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.
2023-06-12 01:59:33 +02:00
### CLI client
Current client **authc** lacks most requests.
### Documentation
2023-06-11 21:10:03 +02:00
Documentation isn't started, yet. TODO!