Would it be viable to use an embedded document roles field for a user table if at most there can be 5 different roles? The reason I ask this is because I believe using an array type for that field would do the same thing. The only time I'd be using the roles field is for checking if the user has the ability to access certain pages/functionality on the website. Am I missing something here? Thanks
I don't really think either approach is incorrect and I think it's more relevant to how you want your models to look than how your data will be stored. It really just depends on what (if any) information aside from the role type that you want to persist and how you plan to check the user's role.
If you're looking to simply store a list of roles (admin, user, moderator, etc) then a serialized array attribute is probably fine. On the other hand, if your roles have more information stored within them (ex. granted actions or privileges for each role) it might be beneficial to build out a UserRole model separately and embed that in your User model.
There is actually another, pretty good option if you're simply storing a list of roles where each user can be a member of one or more roles. You can actually us a bitmask. Using this approach your user roles would be stored as a simple integer and you'd use some of ruby's bitwise operators to map that value to a set of roles.
http://railscasts.com/episodes/189-embedded-association?view=asciicast
Related
So I am using Node/MongoDB (mongoose) to implement this feature.
What I need is the right solution for the following problem:
We have many Company(ies)
Each Company can create it's own Roles
Role is a set of predefined Permissions (like task.create, task.read, task.update, task.delete)
They can choose which Permissions are included in which Role
Company can create it's own Users, and assign them a Role
Lets say that company created 3 roles (the order matters):
Owner (always predefined, has all Permissions)
Team Leader
SuperAgent
Agent
Beside that, I also have Users in a tree structure, with parent reference which holds the _id of the User above him.
The rules are:
User can have none or many children
User cannot be above someone that have higher role than him
User cannot be below someone that have lower role than him
The Tree can get as deep as they want...
So the right representation of this would be:
But because Company Owner can at any time make new Role, or switch the order of roles, the problem occurs...
Let's say he switched the places of 2 roles, and they are now:
Agent
SuperAgent
How would you update all Users?
Also, what if he creates a new Role, puts it in 3rd place, and now needs to update everyone 1 role below, so he can attach that new role to a user...
What approach would you take to solve this kind of issue?
I want to set up a Keycloak instance which provides AAI to several applications. The users and groups will come from multiple sources (e.g. LDAP) so I want to use mappers so that the attributes on the Keycloak side are the same for users with the same properties. For user attributes, one can use a user-attribute-ldap-mapper, and that works like a charm.
My users now are part of groups, and the groups have their own attributes. So for instance I would have in one of my LDAPs:
Group1
-- MySpecificAttribute1: value
-- MySpecificAttribute2: other value
User1:
-- member of Group1
-- MyUserAttriute1: vall
What I would like to do is to map the attributes MySpecificAttribute1 to Attribute1 in the Group1 group that has been imported into Keycloak.
Is there a (hopefully easy) way to achieve this?
EDIT
I thought it could make sense to specify a bit more what I try to achieve. The thing is we are developing an application that needs to have access to the group information, so answering questions like "give me the list of users who are linked in the contactpoint attribute of all groups". Our current approach is to use the REST API to obtain this data directly from keycloak, and it would not be optimal if we had to implement a translation table for the different sources of information. There may be a way to obtain this information in a different way where we would put the translation somewhere in keycloak, that could be worth investigating too.
We are developing an Access application with a SQL Server backend. We have a table that has records that belong to division A, B or C. The users also belong to role A, B or C. We want each user to see only their corresponding division records, as well as only certain columns.
I've thought of two ways, one making different queries for each role and then, based on the user's role, change the source object of the form. However I don't know if it is possible to retrieve it from SQL SERVER with VBA (all VBA documentation I've found so far is quite lacking).
The other solution I thought was to implement this on the server, however I don't know how a T-SQL query or view could fetch only the information needed based on the user's role
Any ideas?
PS: I can't use functions or stored procedures. For some reason the SQL Server we have been provided has them disabled and IT Ops won't enable them (Don't know the logic behind that).
Okay, it's been a while since I posted this but I'll post the solution I came up with in the end. VBA is not quite necessary in this case. It can be done perfectly with views.
To retrieve the users roles, (inner) join the table database_role_members twice with the database_principals one. Join by Id (from database_principals) on both fields. With this, you get a list of all roles and their corresponding users. To get the roles of the user querying the database simply add a where clause that checks that the user name corresponds with the function USER_NAME.
Then, don't give permission to those roles to access the table we want to restrict access to. Instead, make a view that fetches info from that table and add a where clause that looks up the value from a column against the query that retrieves the user roles.
With this you can make a link in access to the view and will allow you to see only the records that correspond to the user roles.
While this approach is easy, it doesn't allow for more complicated row level security. For a more powerful approach it might be useful to check the following link.
https://msdn.microsoft.com/en-us/library/dn765131.aspx
You could create the same tables with different schemas and assign user rights to different schemas. For example, instead of using dbo.Users you could have Accounting.Users and Warehouse.Users. Assign users in an accounting group to the Accouting schema. Or as suggested above those could be views within a schema that select data from underlying tables.
I am new to mongodb and database.
Implement a function to make uid and use the local ObjectId.
Which is better?
You should leave ObjectID generation to the clients/drivers. This makes sure that generated IDs are unique among many things, such as time, server and process. Using the standard ObjectID also means that methods implemented by drivers (such as getTimestamp()) work.
However, if you are thinking of using your own type of ID for the _id field (ie, not the standard ObjectID type), then that makes a viable choice. For example, if you want to store information about a twitter user, then using the user's twitter ID as _id value makes perfect sense. Personally, I try to rely on the ObjectID type as little as I have to, as often collections will have a field in each document already that uniquely identifies each document.
This depends on three things:
Its source
Where and how are you using the user ID?
Personal opinion.
My personal opinion is that the object ID is good enough, however, getting back to the first and second point.
If this ID comes or is to be used in another database like an SQL database you might find using an incrementing ID a good idea, but SQL and other techs do fully support the object ID in the hexadecimal form.
If this ID is something that can be used much like an account number (think of your account number for car insurance when you phone them up) you might find an object ID too difficult for your users to remember/recounter as such a more human friendly ID might be more applicable here.
So it really depends on how this ID is being used.
From the PostgreSQL docs:
The concept of roles subsumes the concepts of "users" and "groups". In
PostgreSQL versions before 8.1, users and groups were distinct kinds
of entities, but now there are only roles. Any role can act as a user,
a group, or both.
Why did they make this change in 8.1?
Perhaps it's easier from the C coders point of view, with a single Role class (struct)?
More details:
CREATE USER is equivalent to CREATE ROLE except that CREATE USER gives the LOGIN permission to the user/role.
(I'm about to design a permission system for my webapp, hence I'm interested in this.)
The merge has many advantages and no disadvantages. For instance, you can now seamlessly convert a "user" to a "group" and vice versa by adding / removing the LOGIN privilege.
ALTER ROLE myrole LOGIN;
ALTER ROLE myrole NOLOGIN;
Or you can GRANT membership in any other login ("user") or non-login role ("group") to a role:
GRANT joe TO sue;
You can still:
CREATE USER james;
That's just a role with login privilege now. Or:
CREATE GROUP workers;
That's effectively the same as CREATE ROLE now.
The manual has it all.
I found this thread in the PostgreSQL-Hackers list, from June 6, 2003, that in the end suggests that users and groups and roles be consolidated. (Thanks Craig Ringer for suggesting that I check the pgsql-hackers list archives.)
Here are some benefits mentioned (those that I found).
allow groups to have groups as members
the ACL code would be simplified
the GRANT/REVOKE syntax and the display format for ACL lists could be
simplified, since there'd be no need for a syntactic marker as to
whether a given name is a user or a group.
In some circumstances I could see it making sense to allow logging in
directly as a group/role/whatchacallit
This would also solve the problem that information_schema views will
show only owned objects
[makes it easier to] representing privileges granted to groups [since
you'd simply reuse the role related code?]
From the manual:
The SQL standard defines the concepts of users and roles, but it
regards them as distinct concepts and leaves all commands defining
users to be specified by each database implementation. In PostgreSQL
we have chosen to unify users and roles into a single kind of entity.
Roles therefore have many more optional attributes than they do in the
standard.
Having a distinction between users and groups doesn't gain you anything.
AFAIK the motivation for changing it was to simplify uses like:
One user masquerading as another, eg a superuser simulating a reduced permissions user. With unified roles this becomes just another change of current role, no different to changing primary group.
Groups that are members of other groups to implement granular access permissions.
If you want the details, though, you're best off checking out the archives of the pgsql-hackers list for the period, and the git history (converted from CVS).