Open pklaschka opened 4 years ago
I would like to move the actual authentication implementation (OAuth or whatever) to simple-server.
isAuthorized
is passed. It has the type signature (req: ExpressRequest, authorizedGroups: string[]) => boolean
and is a function that, based on the request (which could include things like a token or other Auth data) and a list of authorized groups (e.g., ['admins', 'developers']
for one endpoint and ['admins', 'developers', 'project-management']
for another) determines whether the current user is authorized to make that request. It returns true
if the user is authorized and false
if he/she is not.false
, no code may get executed and an HTTP 403
response shall get returnedisAuthorized
is undefined
or null
, no authorization check shall get performed and the authorization (i.e., isAuthorized() === true
) shall get assumedauthorizedGroups: string[]
shall get added as third argument for addModule()
, moving options: *
to fourth position. These groups shall get stored and passed into isAuthorized
when the module gets executed.If accepted (or a modified state, if applicable) shall get added to the https://github.com/server-state/specs repository.
@fussel178 any thoughts?
Sounds good. But for example we add a new user dynamically with his own token to check. This updates (i think) isAuthorized
. Does the server-base call the new function with the new values?
@fussel178 In this case, the new user gets added to a database. isAuthorized
verifies a token (or user or other credentials) with this database every time. It is basically the same as handling it inside server-base, but more flexible and easier to achieve...
Here a small sequence diagram (not really up to UML specs, but who cares :laughing:): sequence diagram
Adding it to the specifications is in progress with server-state/specs#15. Since this, then, will be more of an issue of server-state/simple-server, I'll transfer the issue...
Add capabilities for authentication to allow for restricted access (in the future including roles with different permissions), allowing to secure the actual information (coming from the API) while still serving a Frontend that handles logging in / staying logged in / and so on.
Details of the proposed implementation