This a combination of several ideas I have had over the past few years. With the introduction of https://github.com/GEWIS/gewisdb/pull/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 https://github.com/GEWIS/gewisdb/pull/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.
What would you like?
This a combination of several ideas I have had over the past few years. With the introduction of https://github.com/GEWIS/gewisdb/pull/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:
With this it means we can actually make a split between
401and403errors. Part of GH-1124 can be done by already moving authentication to the route stack(s) (throughauth_typeas introduced in https://github.com/GEWIS/gewisdb/pull/234). This can lead to the removal of theget(Company)UserIdentityOrThrowException()in theGenericAclService. 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.