distinguish between users and managers (different tables, login-endpoints, logic, etc.)
Question:
Create a separate login endpoint and table for regular users and managers (operators that have increased rights access) it’s a good idea?
I can easily merge them into one table (just add status field), one login endpoint.
Currently, they have different login endpoint (login and login-operator), separated tables, etc. So when the operator login – this is a little bit faster to find his hashed password in a separate table and a little bit easier to implement business logic.
My real case/flow:
The user creates a claim, the manager refrormat it by an official approach and sending to correspond organization. So flow is user-claim_from_user-operator-claim_from_operator-organization.
claim_from_user and claim_from_operator has 1 to 1 relation
Answers:
I literally just answered another question and that answer applies here as well – you should be using roles attached to users to separate business logic flows, not building different authentication routes. See this answer.
TL;DR – authenticate all users with the same login flow and use roles to authorize what routes those users are able to interact with.
Create a separate login endpoint and table for regular users and managers (operators that have increased rights access) it’s a good idea?
I can easily merge them into one table (just add status field), one login endpoint.
Currently, they have different login endpoint (login and login-operator), separated tables, etc. So when the operator login – this is a little bit faster to find his hashed password in a separate table and a little bit easier to implement business logic.
My real case/flow:
The user creates a claim, the manager refrormat it by an official approach and sending to correspond organization. So flow is user-claim_from_user-operator-claim_from_operator-organization.
claim_from_user and claim_from_operator has 1 to 1 relation
I literally just answered another question and that answer applies here as well – you should be using roles attached to users to separate business logic flows, not building different authentication routes. See this answer.
TL;DR – authenticate all users with the same login flow and use roles to authorize what routes those users are able to interact with.