Open amotenko opened 6 years ago
Right now we user roles defined on the users table level. The problem with this state is that the roles are defined without a context. Meaning if a User defined as an admin or a camp_manager, and it makes him an admin for all events and for camps or art installations that he/she associates with.
So my first step is to create a table to hold roles data in correct context - with event id and camp id see #594
A question here: We have departments managed in two places - spark and volunteers db. We should have it stored in one db and make this accessible via API
Yes, roles should definitely have their own table, with event ID and I thought, let me know what you think, also with module ID. This way you can open permissions on module by module basis. (modules are not identical to departments, but may overlap sometimes).
Also for additional flexibility, a permission row can contain sub module, so for example an admin for camps in an admin, but a camp manager only controls his camp.
I agree. We should have an auth service, which any system can use and the JWT will include claims for all permissions across modules and across systems.
I did something very similar in Java a couple of months ago for work.
So all the user-related services will be done by a single service for anything Midburn, incl. sign up, roles, login, forgot password, etc Like an active directory for midburn users.
This will also spare us the SSO between Midburn systems development efforts.
I am willing to take this, but I’ll most likely need someone to give me a hand.
While we’re at it, I’d make the authorization process a little cleaner.
It drives me insane that every 10th line is “user.isAdmin” or “user.isManager” If he isn’t an admin, he shouldn’t have reached this code. He should have been rejected by the component verifying the JWT (I think passport can do this...) It will make the code much cleaner IMHO
On 27 Jan 2018, at 13:04, Artyom Katsap notifications@github.com wrote:
A question here: We have departments managed in two places - spark and volunteers db. We should have it stored in one db and make this accessible via API
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
1 - Elad, if you bring the "know how" I'll help to make it happen. 2 - We are talking about user permissions and module permissions as the same thing. Don't know if it is. I think it is different things that might (or not) share implementation details.
In order to allow max flexibility, what we did was give each route (including its route parameters, HTTP verb, etc) a permission.
Once you have permissions at that granular level, you can mix and match them on both the user level and role level.
For the implementation I did for work we also had groups and hierarchy between different roles and different groups, for permission inheritance, but that would be overkill for our current requirement.
Also, I think that now is a good time to discuss and evaluate if we want to move to a CMS, because if so, I believe we will get a more robust solution out-of-the-box. Another important point is we will also get the user management GUI for free, which is another thing will need to implement sooner or later.
On 31 Jan 2018, at 8:35, Artyom Katsap notifications@github.com wrote:
1 - Elad, if you bring the "know how" I'll help to make it happen. 2 - We are talking about user permissions and module permissions as the same thing. Don't know if it is. I think it is different things that might (or not) share implementation details.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
we are using this for auth / permissions etc.. https://github.com/datahq/auth
I think it does everything that you need
and the related angular component - https://github.com/openbudget/budgetkey-ng2-auth - you can see the auth service
you can authenticate 3rd party modules with this central auth service, here is an implementation I'm working on at the moment (using python but can easily be done in any language) - this code verifies with the auth server from the 3rd party module
this is what I'm working on every Monday before I come to the Midburn meeting :)
Nice!
I’ll take a look later. This might be a good option, if we decide not to go the CMS route
On 31 Jan 2018, at 9:57, Ori Hoch notifications@github.com wrote:
this is what I'm working on every Monday before I come to the Midburn meeting :)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Convenient and flexible mechanism for roles and permissions
See discussion here: https://github.com/Midburn/spark/issues/571