I have three types of users "Admin," "Manager," and "Employee." Also, I have an accounts model. All of them can show these accounts. I want to limit employees' access to these accounts. I put the Ids of these accounts in an array and did a limit like the code below. My question is, I had 15 endpoints related to the accounts, Is the best way to do it like this, or may there be a solution that does it without editing all these endpoints?
def index
if #current_user.user_type == 'Admin'
#accounts = Accounts.all
#accounts = optional_paginate(#accounts)
elsif #current_user.user_type == 'Employee'
#accounts = Account.where(id: ACCOUNTS_IDS)
#accounts = optional_paginate(#business_accounts)
else
#business_accounts = optional_paginate(Account.all.includes(:account_managers).exclude_pending)
end
end
The ACCOUNTS_IDS is an array of accounts ids that the employees can access to them only.
Your strategy works, but I think you're sensing that it's not ideal.
You had to hard-code an array of Account IDs from your database, which is never a good idea. If you ever needed to migrate or seed or recreate the database, those IDs could change.
You have this code repeated 15 times(so it's not DRY)
If an account with an id in ACCOUNTS_IDS is ever deleted, imagine what will happen to each of these controller actions.
Adding to or removing from the accounts (ACCOUNTS_IDS) that Employees can see requires you to change your codebase and push those changes.
I'd suggest doing a few things differently:
1. Use an authorization gem
I personally love pundit, but there are other popular options
2. Don't hard-code database information
As mentioned before, the IDs can change and code that relies on a specific record having a specific ID (or relying on that specific record to exist) is brittle.
It's much better to add a column to your table to control this.
Here's an example migration:
add_column :accounts, :restricted, :boolean, default: true, null: false
ACCOUNTS_IDS = [1, 2, 3, 4] #just an e.g.
Account.where(id: ACCOUNTS_IDS).update_column(restricted: false)
:restricted could also be something easier to understand, e.g. :visible_to_employees
Now you can make scopes in your Account model:
# /models/account.rb
class Account < ApplicationRecord
scope :restricted, -> { where(restricted: true) }
scope :unrestricted, -> { where(restricted: false) }
...
end
This allows you to do Account.all to get everything, Account.restricted to get some, and Account.unrestricted to get the others.
This also allows you to add a view form where accounts could be made visible to Employees without having to change the code of your application.
3. Do this in the model, not in the controller
Lean towards having more code in your models and less code in your controllers.
(this will also help you when you implement a Pundit scope)
# models/user.rb
class User < ApplicationRecord
...
def authorized_accounts
case user_type
when 'Admin'
Account.all
when 'Employee'
Account.unrestricted
else
Account.all.includes(:account_managers).exclude_pending
end
end
Now your controller can be greatly simplified:
def index
#accounts = optional_paginate(#current_user.authorized_accounts)
end
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
I want create roles in my project. Each user can be: admin, registered or demo. Each role see different things.
How can I do that? What is the best gem to do roles?
This is a example in 'bad programming" of what I want:
def index
if current_user.role[:name] == 'admin'
#installations = Installation.all
elsif current_user.role[:name] == 'registered'
#installations = current_user.installations
elsif current_user.role[:name] == 'demo'
#installations = current_user.installations.first
else
end
end
Some gems that might be interesting for you :
rolify
role_model
If you decide to implement it yourself, then within some page you might want to change the content, for that you might want to do something like this :
Add a role to the user model using a migration :
class AddRoleToUsers < ActiveRecord::Migration
def change
add_column :users, :role, :string, default: :demo
end
end
Then in your app you can use it as follows:
def index
case current_user.role
when :admin
#installations = Installation.all
when :registered
#installations = current_user.installations
else
#installations = current_user.installations.first
end
end
You can also simply create a boolean admin for instance.
What you might want to do also is create some methods in your model so that you can call current_user.admin? or current_user.registered? . You can do that by doing (if you chose to use a string to store the role):
class User < ActiveRecord::Base
def admin?
self.role == "admin"
end
def registered?
self.role == "registered"
end
end
One advantage I see of having a role stored in a string is that if you have 5 roles for instance then you do not have 4 booleans (as when you store admin in a boolean) but only one string. On the long run you might want to store actually a role_id instead of a string and have a separate role model.
An excellent alternative pointed out by Jorge de Los Santos (another answer) is to use enum :
class User < ActiveRecord::Base
enum role: [:demo, :admin, :registered]
end
It is an excellent alternative because it will automagically add the methods described above such as current_user.admin? without hard coding them.
With your roles, you might want to do some authorization (admins can have access to specific pages, demo users are restricted to only a subset of pages, etc.). For this, you can use the gem called cancancan. You can look at this railscast to learn more about it. Also, you can have some infos here : How to use cancancan? .
There are plenty of solutions available to you.
Starting by gems:
https://github.com/RolifyCommunity/rolify
https://github.com/martinrehfeld/role_model
By using Devise architecture (in case you use it):
https://github.com/plataformatec/devise/wiki/How-To:-Add-a-default-role-to-a-User
By using enums in rails 4:
class AddRolesToUser < ActiveRecord::Migration
#add_column 'role', :integer, default: 0 to the users table
end
class User < ActiveRecord::Base
enum role: [:demo, :admin, :registered]
end
That will enable role methods.
user = User.find(1)
user.role #:demo
user.admin? #false
user.registered? #false
And consequently:
if user.admin?
#somethig
elsif user.registered?
#another something
else
#another another something.
And last but not least, what you are searching is not the manage roles solution, is the manage permissions solutions:
https://github.com/ryanb/cancan
Add a boolean, :admin to your User model.
class AddAdminToUsers < ActiveRecord::Migration
def change
add_column :users, :admin, :boolean, deafult: false
end
end
Create a method for a registered user to separate them from demo users, such as verifying their email, providing a home address and phone number, filling out a profile, etc. This is up to you though, first you need to decide how a registered and demo user should be different.
The CanCan gem adds authorization to your project, and is especially useful if you want to implement multiple roles with differing abilities. When used with an authentication system like devise, you get a full suite of capability for your site.
You're in full control of what roles you want to define and what abilities they have. CanCan manages tracking, assignment, and querying of roles, and then gets out of your way to let you build what you need.
You can find the CanCan gem in Github: https://github.com/ryanb/cancan
It's simple to use, and the documentation is straightforward and easy to follow.
So for some reason, my client will not drop inactive users from their database. Is there a way to globally exclude all inactive users for all ActiveRecord calls to the users table?
EX: User.where("status != 'Inactive'")
I want that to be global so I don't have to include that in EVERY user statement.
Yes, you can set a default scope:
class User < ActiveRecord::Base
default_scope where("status != 'Inactive'")
end
User.all # select * from users where status != 'Inactive'
... but you shouldn't.
It will only lead to trouble down the road when you inevitably forget that there is a default scope, and are confused by why you can't find your records.
It will also play havoc with associations, as any records belonging to a user not within your default scope will suddenly appear to belong to no user.
If you had a simple setup with posts and users, and users had a default scope, you'd wind up with something like this:
# we find a post called 1
p = Post.first # <#post id=1>
# It belongs to user 2
p.user_id # 2
# What's this? Error! Undefined method 'firstname' for `nil`!
p.user.first_name
# Can't find user 2, that's impossible! My validations prevent this,
# and my associations destroy dependent records. Can't be!
User.find(2) # nil
# Oh, there he is.
User.unscoped.find(2) <#user id=2 status="inactive">
In practice, this will come up all the time. It's very common to find a record by it's ID, and then try to find the associated record that owns it to verify permissions, etc. Your logic will likely be written to assume the associated record exists, because validation should prevent it from not existing. Suddenly you'll find yourself encountering many "undefined method blank on nil class" errors.
It's much better to be explicit with your scope. Define one called active, and use User.active to explicitly select your active users:
class User < ActiveRecord::Base
scope :active, -> where("status != 'Inactive'")
end
User.active.all # select * from users where status != 'Inactive'
I would only ever recommend using a default_scope to apply an order(:id) to your records, which helps .first and .last act more sanely. I would never recommend using it to exclude records by default, that has bitten me too many times.
Sure, in your model define a default scope
see here for more info
eg
class Article < ActiveRecord::Base
default_scope where(:published => true)
end
Article.all # => SELECT * FROM articles WHERE published = true
As an alternative to #meagar's suggestion, you could create a new table with the same structure as the Users table, called InactiveUsers, and move people into here, deleting them from Users when you do so. That way you still have them on your database, and can restore them back into Users if need be.
I have a multiple select box for a has_many association. The params come in as:
foo_ids: ["1", "2", "3"]
Using strong parameters, I do not permit this attribute because I would like to authorize it myself so people cannot just put whatever they want in it.
def update
bar.foos = authorized_foos
bar.update(baz_params)
respond_with bar
end
private
def authorized_foos
foos = Foo.find(params[:baz][:foo_ids])
foos.each do |foo|
authorize foo, :manage?
end
end
This approach is going to force me to find all of the foos, loop through them, and authorize each one individually. Is there an easier way to manage has_many authorization, preferably with the Pundit gem?
The simplest way to do this is looping. Iterate through each user from the users' array and authorize each and every user.
For example,
users_id_array = [1,2,3,4,5,6]
private
def authorized_users
users = User.find(params[:group][:user_ids])
users.each { |u| authorize u, :manage? }
...
end
So this is the very basic and simplest answer.
I do something similar to this. Because of how little info you've provided I'm going to make a swath of assumptions.
You have a many to many association of foos to users. By this I mean a foo can have many users and a user can be a member of many foos.
You understand how to set-up the models to attain (1). If you don't just comment and I'll edit this response.
So what we will need to have working for this to work is the following:
#foo.users returns a collection of users
#user.foos returns a collection of foos
With the models set up to support the actions above this is much easier than you are making it out to be.
class FooPolicy < ApplicationPolicy
class Scope < Scope
def resolve
user.foos
end
end
end
I think you're missing the point of pundit. Pundit allows you to do authorization on a user by user basis. So the above code scopes a user to only the groups (foos in this case) that they are a part of.
I have users in my system that can elect to 'hibernate', at which point they can remove themselves and all of their associated records entirely from the system. I have queries all over my site that search within the User table and its associated tables (separated by as many as 5 intermediate tables), and none explicitly test whether the user is hibernating or not.
Is there a way to redefine the User set to non-hibernating users only, so all my current queries will work without being changed individually?
How can I most elegantly accomplish what I'm trying to do?
This is typically done with default scopes. Read all about them
Code from Ryan's site:
class User < ActiveRecord::Base
default_scope :hibernate => false
end
# get all non-hibernating users
#users = User.all
# get all users, not just non-hibernating (break out of default scope)
#users = User.with_exclusive_scope { find(:all) } #=> "SELECT * FROM `users`