I need to know that how we can implement dynamic role on hasura.I mean if we have lots of tables and want to have 4 access control per the table (insert, delete, update, select), a one way is that we create 4 roles for each table for example if we had two tables that named users, cars, we would have these roles:
1-add_user
2-delete_user
3-update_user
4-select_user
and
5-add_car
6-delete_car
7-update_car
8-select_car
it is not a efficient way...
please help me to find the best way.
thank you.
As far as my understanding goes of roles, in your case role will just be user. Your tables users and cars will have permissions assigned to user role. So for e.g
Role user will have (insert, delete, update, select) permissions for
users table but can only have (select) permission for cars table.
For implementation, you can easily create them in permission section of your respective table.
Let me know if this was helpful to you or if you have any furthur doubts.
Related
I have a (skills) table and (users) table, and I have created (skill_user) table as a pivot,
but my problem is how can I let the user insert any skills he wants, and at the same time it is many to many relationships, which means the user should select the skills which already exist? i cannot understand how can I fix this issue?
There are 3 methods to work with many-to-many relationships:
attach
detach
sync.
I would say sync is more suitable for your case: user selects a list of skills, and you save only these. This also allows to remove skills if user unselected one.
I want to create simple SPA with admin-panel. I did panel and fronted part. Now I have two solutions way:
Use enum type of row in database: $table->enum('role', ['user', 'admin]);
Create another 'roles' table and insert there: 'user' and 'admin'
Which is the better way and why?
Always try to go for the simplest, clearest solution. As long a you only have 2 roles, admin and user, and a customer can only have one role, the first solution is much easier.
Defining a new table would give unwanted complexity, and also to ask for each user it's role from a different table could be timeconsuming.
Perhaps if you have more roles, and a user can have multiple roles, the second solution is more clear.
What is the correct way to relate users in parse to one another as friends?
I also want users to be able to query other users but not see all fields, like emails. Is there a way I can create a view on the users table with cloud code, and only return this to the client code?
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
thanks for any advice.
I was thinking I can create a friends table that will have two columns with 2 pointers, 1 for each user.
I'll do that too, with a status column to handle pending, blocked...etc
I also want users to be able to query other users but not see all fields, like emails.
You have to add a privateData column on user with ACL restricted to owner only, which would contain private infos such as emails...etc
The scenario : an Oracle 11g database containing some sensitive user data that could result legal liabilities if disclosed to the wrong party.
The desired effect : only a certain user, connecting from a certain IP, can see the column that contains this sensitive user data
I am not sure that hidden columns or virtual columns are the right ways to do this. It seems that Fine-Grained Access Control could help. I am not sure of what is the best solution. The restriction by IP is probably done at the listener level?
The question :
How can we restrict the visibility of a column so it is only available only to a specific user? All the other users would never see the column, not even when doing a "DESC TABLE_WITH_SENSITIVE_DATA"
Thanks for any tips.
Simplest way to do this is to create a view on the table that does not contain all of the columns. Don't grant select on the table, but only on the view.
The "proper" way to do this is with Fine-Grained Access Control (Virtual Private Database), which can replace the contents of columns with a NULL if certain conditions are not met.
See the example here: http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#autoId17
You can probably build this sort of functionality yourself if you're feeling both impoverished and skilled.
Do you the ability to modify roles and create views? Perhaps you could create two separate views and grant access to two different roles for that table. All users that are restricted from seeing the sensitive data would belong to a "restricted" role and the others would have access to the "unrestricted" role. You would need to grant privileges on each view to the appropriate role.
It is important to note that there are restrictions on updating the underlying data associated with a view. As explained here, views that contain set operators, aggregates and GROUP BY DISTINCT and joins and not modifiable.
What is the purpose of this table? From it's name, could we assume that it lists all rights assigned to each user?
If we need to know what right are assigned to which user, should we look only this table? Or there is another table to read?
What is the purpose of this table?
It contains the list of rights of users and roles.
Or there is another table to read?
Yes. You also need to know what roles are assigned to a user: INFORMATION_SCHEMA.ROLES