Rewrite authentication (and authorisation) logic
Opened this issue · 1 comments
What would you like?
This a combination of several ideas I have had over the past few years. With the introduction of GEWIS/gewisdb#234 in GEWISDB we have a better idea of how we are supposed to do this.
The authentication flow is re-done to better account for the several "account" types that we have:
- GEWIS user,
- Company user, and
- API user.
With this it means we can actually make a split between 401 and 403 errors. Part of GH-1124 can be done by already moving authentication to the route stack(s) (through auth_type as introduced in GEWIS/gewisdb#234). This can lead to the removal of the get(Company)UserIdentityOrThrowException() in the GenericAclService. Furthermore, we should move the IP range check partially towards our memcache (or a new redis instance).
This will include GH-1557 and will allow for more API functionalities in the future (e.g. GH-1046).
Why is this needed?
Simplification of our existing systems. Even with my 4+ years of experience with this codebase the authentication and authorisation aspects of it are the most difficult to work with/understand in my opinion.
Other information
When changing the API authentication, we will break any existing setup.
We have to be careful which routes we mark as requiring a login. For example, the course document download must always be accessible (so AUTH_NONE) for tueguest to work.