Module: Authentasaurus::Authorization

Defined in:

lib/authentasaurus/authorization.rb

Overview

Authorization Helpers

The authorization module provides helpers for restricting access to your controllers.

Each controller is considered an area in Authentasaurus, for example UsersController stands for “users” area. Each area must be defined in the Areas table so Authentasaurus can control access to it.

Authentasaurus provides a simple rake task to define areas automatically:

rake authentasaurus:create_areas

Restricting Access

You can restrict access to any controller using one of the following class methods on your controller.

At login, Authentasaurus will load the permissions of the group the user belongs to in the session and will use them to authorize access to the area.

There are three levels of restriction in Authentasaurus, login, read and write; with the exception of login, read and write don’t have any logic behind them; they are defined using the Permission and are only symbolically named i.e.: you can use read instead of write and vice versa it only depends on how you use them.

Restricting access to logged in users

You can restrict access to an area to logged in users only using the ActionController::ClassMethods#require_login class method.

Consider the following example restricting access to the pages controller to only logged in users:

class PagesController < ActionController::Base
  require_login
  ... 
end

You can also specify which actions to restrict:

require_login :new, :create, :index

Authentasaurus will automatically redirect users to the sign-in page if they try accessing the area while they are not logged in. Once the user logs in he/she is redirected back to his/her original destination unless you explicitly skip that behaviour:

require_login :skip_request => true

Restricting access according to permissions

Unlike the login restriction, permissions restrictions checks if the user is logged in and has the permission to access the area.

Users get permissions from their parent group and permissions are dynamically set in the database.

Authentasaurus currently supports only two permissions, read and write, both permissions are symbolically named, they have no meaning.

Restricting access to users with read permission

class PagesController < ActionController::Base
  require_read
  ...
end

ActionController::ClassMethods#require_read takes the same options as ActionController::ClassMethods#require_login and ActionController::ClassMethods#require_write

Restricting access to users with write permission

class PagesController < ActionController::Base
  require_write
  ...
end

ActionController::ClassMethods#require_write takes the same options as ActionController::ClassMethods#require_login and ActionController::ClassMethods#require_read

Checking if the user is logged in in actions or views

Along with the class helpers, Authentasaurus includes a helper to check if the user is logged in inside any of your actions:

is_logged_in?

Check ActionController::CommonInstanceMethods#is_logged_in? for more information.

Checking permissions in actions or views

You can also check if the logged in user has a certain permission.

Consider the following example to check if the logged in user has read permission on the current area

has?(:read)

You can also check permissions on an area while in another, for example to check if the current user has write permission on the users area:

has?(:write,:users)

Check ActionController::CommonInstanceMethods#has? for more information.

Retrieving the current user in actions or views

To get the logged in user you can use the following helper:

current_user

Check ActionController::CommonInstanceMethods#current_user for more information.

Defined Under Namespace

Modules: ActionController, ActionView, CommonInstanceMethods