maybee
Simple Model-Based Authorization for Rails.
Install
# Gemfile
gem 'maybee'
Usage
In maybee, subjects may do the things that objects allow them to do.
To have an authorization subject, which will in most cases be your user model:
class User < ActiveRecord::Base
acts_as_authorization_subject
end
To have models that act as authorization objects, i.e. something that users may or may not use:
class Car < ActiveRecord::Base
acts_as_authorization_object
end
Defining access rules
Access rules are defined inside models using a simple DSL and may be named as you like. A named rule like
class Car < ActiveRecord::Base
acts_as_authorization_object
allows to: :drive
end
will have model instances respond true
if asked
car.allow?(:drive, user)
=> true
Usually, you will want to restrict access based on some internal state of the model (the authorization object) or the user (the subject). This can be accomplished using the options :if
, :unless
, :if_subject
and :unless_subject
:
allows to: :drive, if: :license_plate_valid?, if_subject: :has_drivers_license?
With this declaration, the car would allow any (ruby) object to drive, if the car has a valid license plate and the ruby object responds to #has_drivers_license?
with a true value.
In order to limit the access to instances of a certain class, you can include the desired subject class(es) in the rule definition:
class User < ActiveRecord::Base
acts_as_authorization_subject
end
# only some users are actual drivers
class Driver < User
def sober?
0 == self.drinks
end
end
class Car < ActiveRecord::Base
acts_as_authorization_object
allows :drivers, to: :drive, if_subject: :sober?
end
This will allow sober drivers to drive, but will reject normal users and drunk drivers.
If you do not care for the subject class, you may also write
allows_to :drive, if: ...
which is the same as allows to: ...
Multiple access rights may be given in the same definition:
allows :drivers, to: [:start, :drive], if: ...
Passing blocks
It is also possible to pass a proc to any of the conditional options:
allows :drivers, to: :start, if: lambda { |driver| gasoline_level > 0 }
Blocks passed to :if
and :unless
are evaluated inside the authorization object, while :if_subject
and :unless_subject
get evaluated inside the authorization subject (the user).
Dealing with nil
In most cases, you will want to restrict authorizations to authorized subjects only. So maybee will refuse any access by default if the subject is nil
. For the special case where an access should also be granted if the subject is nil, use the :allow_nil
option:
class Image
allows :users, to: :view, if: :publicly_accessible?, allow_nil: true
allows :users, to: :view, if_subject: lambda { |image| self.company_id == image.company_id }
def publicly_accessible?
# implementation, or a simple attribute
end
end
This would allow anyone (including nil
) to view an image if it is publicly accessible, and allow users to view the images belonging to the same company as the user.
Authorizing create, update and destroy on the model level (in an MVC way)
There are three special accesses which limit creation, updating and destruction of records. By default, if a model is an authorization object, it will prevent new records from being created, and existing ones from being updated or destroyed. As models by default do not know about the application's current_user
, maybee defines an attr_accessor
on auth objects where the authorization_subject
can be set by the controller.
In the simplest form, the access to create, update and destroy would be granted regardless of the authorization_subject
. This would be the default behaviour of ActiveRecord, where besides validations there is no restriction on these operations:
allows_to :create, :update, :destroy, allow_nil: true
Say you have models for users and roles, and you want normal users not to be able to assign roles, but only admins:
class User < ActiveRecord::Base
acts_as_authorization_subject
has_many :user_roles, dependent: :destroy
has_many :roles, through: :user_roles
end
class Role < ActiveRecord::Base
end
class UserRole < ActiveRecord::Base
belongs_to :user
belongs_to :role
acts_as_authorization_object
allows :users, to: [:create, :update, :destroy], if_subject: :admin?
end
Just adding a role to a user is no longer possible this way, as the association object UserRole
requires an admin subject to be set in order to be created.
user_role = user.user_roles.build
user_role.save
=> false
user_role.authorization_subject = current_user # current_user is an admin
user_role.save
=> true
Enforcing rules
The idea behind maybee was to do things in an explicit way, so it doesn't do any magic in the background, but it provides your implementation with methods to determine whether an access is authorized or not.
In a classic Rails application, the controller is responsible for restricting access to objects. However, more complex rules of what is allowed and what is not should not go into the controller code, but be placed inside the model itself. This is where maybee can be used.
class ImagesController < ApplicationController
before_action :find_image
def show
render
end
private
def find_image
@image = Image.find_by_id(params[:id]) or return(not_found)
@image.allow?(:view, current_user) or return(forbidden)
end
end
Instead of allow?
you can always write user.may?
current_user.may?(:view, @image)
User feedback
Usually, you want to give some feedback to the user when she attempted an access which was denied. Maybee provides two authorization query methods which set an error on the record every time an access was denied.
@image.authorize?(:destroy, user)
sets an error on the image instance when the user is not allowed to destroy it.
current_user.authorized_to?(:destroy, @image)
is equivalent.
Default authorization subject
For more generic implementations the subject argument to authorize?
and allow?
can be left out. It will then default to the value of the authorization_subject
accessor, which should be set before, for example in a before_filter
.
Inheritance
By default, access rules are inherited by subclasses of auth objects. Additional rule definitions on the subclass extend the accesses possible on that class. If you want to redefine an access on a subclass without inheriting the access rules from its superclass, you can use the exclusive
option:
class Foo < ActiveRecord::Base
allows_to :view, if: :visible?
end
class SubFoo < Foo
allows_to :view, exclusive: true
end