I have User and Role models in many-to-many relations via UserRoleAssoc in Ruby-on-Rails.
I need a page (web interface) from which a user can add/delete roles associated with a user, where ordinary users but administrators can edit the roles for themselves only.
My question is how to implement the scheme, particularly authorization.
Here are the models of User and Role (just the standard many-to-many):
class User < ApplicationRecord
has_many :user_role_assocs, dependent: :destroy
has_many :roles, through: :user_role_assocs
end
class Role < ApplicationRecord
has_many :user_role_assocs
has_many :users, through: :user_role_assocs
end
class UserRoleAssoc < ApplicationRecord
belongs_to :user
belongs_to :role
end
According to DHH's principle (cf. "How DHH Organizes His Rails Controllers" by Jerome Dalbert), such actions should be implemented as if a controller, say, ManageUserRolesController, does one or more of the CRUD actions. In this case, ManageUserRolesController either or both of create and delete multiple records on UserRoleAssoc.
Since the web user interface should enable one to manage a list of roles (with a select box) in one go from a URL, I made the create method of ManageUserRolesController does both, receiving User-ID (user) and an Array of Role-IDs (roles) in params (I'm open to suggestions, though!). routes.rb is as follows:
resources :manage_user_role, only: [:create] # index may be provided, too.
Now, to restrict a user to add/delete roles to any other users, I would like to write in models/ability.rb something like, along with a Controller:
# models/ability.rb`
can :create, ManageUserRoles, :PARAMS => {user: user} # "PARAMS" is invalid!! Any alternative ideas?
can :manage, ManageUserRoles if user.administrator?
# controllers/manage_user_roles_controller.rb
class ManageUserRolesController < ApplicationController
load_and_authorize_resource
end
It seems possible to achieve it in the way described in an answer to "Passing params to CanCan in RoR" and CanCan wiki, though I think the model corresponding to the controller has to be defined to point the non-standard table, in models/manage_user_role.rb
class ManageUserRole < ApplicationRecord
self.table_name = 'user_role_assocs'
end
But this seems quite awkward…
What is the 'Rails' way (Version 6+) to implement authorization of many-to-many models? To be specific, what is a good interface to add/delete multiple roles to a user with some constraint?
Note that the route doesn't have to be like the sample code above; the route can be set so that a user-ID is passed as a part of the path like /manage_user_role/:user_id instead of via params, as long as authorization works.
Here is an answer, a solution I have used in the end.
Background
Many-to-many relation is by definition complex and I do not think there are any simple solutions that fit all cases. Certainly, Ability in CanCanCan does not support it in default (unless you do some complicated hacks, such as the way the OP wanted to avoid, as mentioned in the Question).
In this particular case of question, however, the situation which the OP wants to deal with is a constraint based on the user ID, which is basically a one-to-many (or has_many) relation, namely one-user having many roles. Then, it can actually fit in the standard way as Cancancan/Ability works.
General speaking, there are three ways to deal with the OP's case of many-to-many relation between users and roles (i.e., each user can have many roles and a role may belong to many users):
handling it as in the User (Controller) model,
handling it as in the Role (Controller) model,
or UserRoleAssoc (Controller), that is, a model associated with the join table between User and Role (n.b., this Controller is not created by default and so you must create it manually if you use it).
Let me discuss below which one of the three best fits the purpose with Cancancan authorization.
How Cancancan authorizes with Ability and what would fit this case best
For the default CRUD actions, Cancancan deals with a can statement as follows (in my understanding); this is basically a brief summary with regard to this case of the official reference of Cancancan:
for the action index, only the information Cancancan has is the User, the Model Class (with/without scopes), in addition to the action type index. So, basically, Cancancan does not and cannot do much. Importantly, a Ruby block associated with the can statement, if any, is not called.
if the (primary) ID of the model is given in the path, namely for the actions of show, edit, update, destroy, Cancancan retrieves the model from the DB and it is fed to the algorithm you provide with the can statement, including a Ruby block, if given.
In the OP's case, a user should not be authorized to handle the roles of any other users but of her/himself. Then, the judgement must be based on the two user-IDs, i.e., the one of current_user and the one given in the path/route. For Rails to pick up the latter from the path automatically, the route must be set accordingly.
Then, because the "ID" is a User-ID, the most natural solution to deal with this case is to use UsersController (case 1 in the description above); then the ID included in the default route is interpreted as User#id by Rails and Cancancan. By contrast, if you adopt case 2, the default ID in the path will be interpreted as Role#id, which does not work well with this case. As for case 3 (which was mentioned in the question), UserRoleAssoc#id is just a random number given to an association and has nothing to do with User#id or Role#id. Therefore, it does not fit this case, either.
Solution
As explained above, the action of the Controller must be selected carefully so that Cancancan correctly sets the User based on the given ID in the path.
The OP mentions create and delete (destroy) for the Controller. It is technically true in this case that the required actions are either or both of to create and delete new associations between a User and Roles. However, in Rails' default routing, create does not take the ID parameter (of course not, given the ID is given in creation by the DB!). Therefore, the action name of create is not really appropriate in this case. update would be most appropriate. In the natural language, we interpret it such that a user's (Role-association) status will be update-d with this action of a Controller. The default HTTP method for update is PATCH/PUT, which fits the meaning of the operation, too.
Finally, here is the solution I have found to work (with Rails 6.1):
routes.rb
resources :manage_user_roles, only: [:update]
# => Route: manage_user_role PATCH /manage_user_roles/:id(.:format) manage_user_roles#update
manage_user_roles_controller.rb
class ManageUserRolesController < ApplicationController
load_and_authorize_resource :user
# This means as far as authorization is concerned,
# the model and controller are User and UsersController.
my_params = params.permit('add_role_11', 'del_role_11', 'add_role_12', 'del_role_12')
end
View (to submit the data)
This can be in show.html.erb of User or whatever.
<%= form_with(method: :patch, url: manage_user_role_path(#user)) do |form| %>
Form components follow...
app/models/ability.rb
def initialize(user)
if user.present?
can :update, User, id: user.id
end
end
A key take is, I think, simplifying the case. Though many-to-many relations are inherently complex, you probably better deal with each case in smaller and more simple fragments. Then, they may fit in the existing scheme without too much hustle.
Related
I am working on a Ruby on Rails application that has two kinds of "Roles".
One will be where a user has multiple roles, such as "Admin", "Team Lead", etc. these will be defined in the seeds file and not generated by the user.
The other will be generated by a User and assigned to other users, such as "Chef", "Waiter", etc.
They are both similar in that they only have a name column. The former will be used with an authorization tool such as CanCanCan. I currently plan to allow users and roles to have many of the other using a has_many :through relationship.
class Role
has_many :user_roles
has_many :users, through: :user_roles
end
class User
has_many :user_roles
has_many :roles, through: :user_roles
end
class UserRole
belongs_to :user
belongs_to :role
end
My questions are:
Should the latter ("Chef", "Waiter", etc) be put in the same table? Separate tables?
Should I use some kind of inheritance?
What's a good practice for this situation?
I plan to use the term "Role" in the user interface for the latter, showing what "Roles" a user has. The former I guess is more about what privileges they have within the application.
If you go away from the technical side of roles and authentication, and try to describe the "things" from a more business oriented approach you make the distinction clearer for yourself.
What I understand is: You have a definition for a user of your application that is used to describe what authorization this user has, e.g. an "admin" has more rights than an "editor" or "community manager".
You also want these users of your application to be able to create names that are associated with (other?) users. Theses names have nothing to do with authorization, as I understood.
Maybe these names are more like tags, that people can assign?
I would keep both separated, as it shouldn't be able for a user to create a role, or modify existing roles, that could grant them access to admin features.
If you want to look at a tagging gem, I could recommend this one: https://github.com/mbleigh/acts-as-taggable-on I used this for several years and while it has its drawbacks, it's reliable.
I'd suggest having a look at rolify before rolling your own solution, as it will have solved some things that you'll have to reimplement / discover later (e.g. role queries, avoiding N+1 queries etc). It also integrates well with can?, and should work well for the authorisation part of your question.
Whilst it's not impossible to allow users to create new roles (by throwing an input form on top of Role.create), this starts to get messy, as you need to track which ones are for authorisation and which ones informative (and user created).
Since the two groups of things are for different purposes, I wholeheartedly agree with this other answer that it's cleaner to separate the user-generated entities, and look to implement them as tags. You may display all the "roles" together in certain views, but that doesn't mean that it makes sense to store them within a single table.
Side-note: if you do end up rolling your own solution, consider using HABTM here. The join table will still be created, but you won't have to manage the join table model. E.g.
has_and_belongs_to_many :users, join_table: :users_roles
Since you only have a limited number of roles, you could use a bitmask and store directly on the user model as a simple integer.
See this Railscasts for more information. That would be the most efficient, database and association wise, way to do this although perhaps not the simplest to understand. The only real restriction is that you can't alter the array of values you check against, only append to it.
Good luck!
I would create one more model, Permission, where you can create a list of all the permissions you want to manage under any given role.
Then have a many to many between Permissions and Roles.
From a UserRole instance then you will be able to list the permissions, and in the future you could add additional permissions to roles buy just running inserts in a couple of tables
Roles: Onwer, Chef, Cook, Waiter
Permission: can_cook, can_buy_wine, can_manage, can_charge_custome
Owner: can_manage, can_buy_wine, can_charge_customer
Chef: can_cook, can_manage
Waiter: can_charge_customer
Is would be a good start and you can evolve the role functionality to whatever your needs are without an external dependency.
Also, You can go just using Users table and adding role column as integer and give them a role code in default 0 integer.
#app/helpers/roles_helper.rb
module RolesHelper
#roles = {
'Default' => 0,
'Waiter' => 10,
'Chef' => 20,
'Superadmin' => 30
}
class << self
def list_roles
#roles.map{|k,v| [k,v] }
end
def code(str)
return #roles[str]
end
def value(id)
return #roles.key(id)
end
end
def require_default_users
unless current_user && current_user.role >= RolesHelper.code('Waiter')
redirect_to root_url(host: request.domain)
end
end
def require_superadmin_users
unless current_user && current_user.role >= RolesHelper.code('Superadmin')
redirect_to courses_path
end
end
end
access in controllers
sample:
class Admin::AdminController < ApplicationController
include RolesHelper
def sample_action_method
require_default_users #if non admin user redirect ...
puts "All Roles: #{RolesHelper.list_roles}"
puts "Value: #{RolesHelper.value(30)}"
puts "Code: #{RolesHelper.code('Superuser')}"
end
end
Is it considered bad practice (or un-RESTful) to create nested routes for resources that otherwise have no association? For example I have:
resources :foos do
resources :bars
end
But I have no business logic elsewhere in my database or application that associates :foos with :bars.
The reason I want to do this: Many of my routes are created as resources nested under my :groups resource. I do that so that I can always grab a group_id param and always show a layout that matches the group the user is currently "in". I'm comfortable with this when the resource belongs_to the group:
/groups/1/comments/1
But when some other comment does not belong_to the group (group1) and I want to look at it through layout that is "branded" as group1, my impulse is to route it like this:
/groups/1/comments/2
Is this ok to do, maybe I'm overthinking this?
I maintain an app with similar requirements. I do something roughly along the lines of:
class User
has_and_belongs_to_many :groups
belongs_to :active_group, class_name 'Group'
def active_group
return super unless super.nil?
group = groups.first
update_columns(active_group_id: group.id)
group
end
end
The User class validates that they are assigned to one or more groups and the active_group method is overriden to provide a default if it is a first login. With this approach you will need to provide an action to set the active group so the user can switch groups (presumably this is a requirement).
This assumes that you have some kind of authentication in place to know the current user. If restricting access to groups is not a concern, you can forego the habtm relationship and substitute groups.first with Group.first.
If you don't have/want/need authentication, you could just drop a active_group_id in the session cookie. But I would definitely consider it bad practice to nest unrelated resources.
I want to make a record management system. The system will have 4 different user roles: Admin, Viewer, Editor and Reviewer.
While the first two are easy to implement using gems such as cancan and declarative authorization, the other two are not so simple.
Basically each new record is created by an Admin (only an Admin can create new records), and should have its own separate Editor and Reviewer roles. That is, a user can be assigned many different roles on different records but not others, so a user might be assigned Editor roles for Record A and C but not B etc.
Editor: can make changes to the record, and will have access to specific methods in the controller such as edit etc.
Reviewer: will be able to review (view the changes) made to the record and either approve it or submit comments and reject.
Viewer: Can only view the most recent approved version of each record.
Are there any ways of handling such record-specific user roles?
This can be accomplished without too much effort with the cancan gem and a block condition. A block condition checks for authorization against an instance. Assuming your Record class had an editors method that returns an array of authorized editors the cancan ability for updating a Record might look something like this:
class Ability
include CanCan::Ability
def initialize(user)
user ||= User.new # guest user (not logged in)
...
can :update, Record do |record|
record.editors.include?(user)
end
...
end
end
See "Block Conditions" on the CanCan wiki:
https://github.com/ryanb/cancan/wiki/Defining-Abilities
Update
Storing which users have which access to which records could be done many ways depending on your specific needs. One way might be to create a model like this to store role assignments:
class UserRecordRoles < ActiveRecord::Base
# Has three fields: role, user_id, record_id
attr_accessible :role, :user_id, :record_id
belongs_to :user_id
belongs_to :record_id
end
Now create a has_many association in the User and Record models so that all role assignments can be easily queried. An editors method might look like this:
class Record < ActiveRecord::Base
...
has_many :user_record_roles
def editors
# This is rather messy and requires lot's of DB calls...
user_record_roles.where(:role => 'editor').collect {|a| a.user}
# This would be a single DB call but I'm not sure this would work. Maybe someone else can chime in? Would look cleaner with a scope probably.
User.joins(:user_record_roles).where('user_record_roles.role = ?' => 'editor')
end
...
end
Of course there are many many ways to do this and it varies wildly depending on your needs. The idea is that CanCan can talk to your model when determining authorization which means any logic you can dream up can be represented. Hope this helps!
I'm working on a rails app and using a singular resource. However the controller name for the singular resource is plural.
Eg map.resource activity_report expectes the activity_reports_controller.
The explanation given in the rails 3 guide is: "... you might want to use the same controller for a singular route and a plural route..." That is a reasonable explanation, but what is the use case for using the same controller to handle a singular route and a plural route?
In a RESTful Rails application there is usually a mapping of one controller per RESTful resource. For example, let's say we wanted a controller to process user logins (/session) but also to provide a list of users who are currently logged in (/sessions). Logically we could put both of those responsibilities within a SessionsController:
class SessionsController < ApplicationController
# GET /sessions
# Display a list of logged in users
def index
...
end
# GET /session/new
# Display the login form
def new
...
end
# POST /session
# Authenticate a user
def create
...
end
end
An alternative would be to split the functionality for listing logged in users out into a separate administration controller.
You can use it.
class UsersController < Application
end
map.resource :user
map.resources :users
Another situation in which I can imagine using it would be, let's say (and this isn't necessarily the business model you'd want, but stay with me for a moment) you are going to make a site of film reviews, and film information. So, on the one hand you'd have the link to your list of the latest reviews be a plural resource route, something like this:
http://yoursite.com/reviews?count=5
So, in this case, you have a controller for the collection, right? But you're only going to review each movie once. So what if you wanted to provide an easy access to a movie's review?
http://yoursite.com/movies/pirates_of_the_carribean_2/review
Well, there's a nested single resource route, because a movie has_one review, right?
I have a User model with the usual information (login, email, name, location, etc). However, when users decide to edit their information, I'd like to separate the fields to be edited according to the appropriate concerns.
For example, I'd like to have Name, Bio and Location to be edited on a Profile page or tab, and login, email and password to be edited on an Account page or tab.
What are the best practices, and the safest way, to accomplish that? Should I have two separate model/resources: User and UserProfile? Or can I just create something like a profile method in the UserController, with a custom form with only the specific profile fields, and link to it in the user page? I'm really confused on how to go about this.
Thanks in advance for any ideas you might have.
I think it depends on the rest of your Application. It sounds like in your case it's good to be modular. If you want users to be able to see the profile of other users, it's an advantage to have a separate model for the Profile and like it with a has_one relationship. I'd just call the class Profile so it can be accessed through user.profile in your controllers and views.
Models:
class User < ActiveRecord::Base
has_one :profile, :dependent => :destroy
end
class Profile < ActiveRecord::Base
belongs_to :user
end
If all your users have both profile and account fields then I wouldn't put it in seperate models. It will only add unnecesary complexiety to your forms and add may add some sql queries.
I don't see here any security problems. In case of editing, both actions (edit account and profile) should be protected the same way - so only owner user should be able to edit both of them. If he want to "hack" it and edit also his login when he edits his first name then it is his problem. It won't cause any problem since he is allowed to edit both fields.
According to views that are viewable for other people: just don't display there any fields that belongs to account part.
How to seperate it? For me the cleanest way is to add this kind of routes:
map.resources :accounts
map.resources :profiles
And use paths like /accounts/34/edit to edit account part and /profiles/34/edit to edit profile part.
In this case you will need a seperate controller for both routes: accounts_controller.rb and profiles_controller.rb. If they share a lot of similar methods and behavior, you can add it in users_controller.rb and in profiles and accounts controllers inherit from it.
You can also do it with one controller:
map.resources :accounts, :controller => 'users'
map.resources :profiles, :controller => 'users'
But I don't know how to pass some additional value with routes created with resources. When you use connect you can pass it with :defaults => {:foo => 'bar'} and then it will be availble in controller as params[:foo] but it doesn't seem to work with resources. So how can you distinguish between accounts and profiles? You can read it from current url (here is example). And then in controller you can render different views according to requested resource.
I would be inclined to cut along the grain here. It's going to be easier to map a model to a form. So if you have information that is accessed within different forms in your UI, I would create a model for each.
That said, at a certain point in my systems I tend to pull the profile information out of the base User class, so the User becomes solely for authentication.