In part one of this series, we looked at some basic usages of Action Policy. Now we'll leverage Action Policy for more advanced authorization use cases.
First up, let's explore applying pre-checks.
Pre-checks
Let's say we want users with "editor" status to have access to a post's show
, update
, and destroy
actions, like so:
# app/policies/posts_policy.rb
class PostPolicy < ApplicationPolicy
def show?
user.editor || user.reader || user.id == record.user_id
end
def update?
user.editor || (user.id == record.user_id)
end
def destroy?
user.editor || user.id == record.user_id
end
end
We can refactor this policy code using an Action Policy pre-check that extracts common rules into pre-checks
:
# app/policies/posts_policy.rb
class PostPolicy < ApplicationPolicy
pre-check :allow_editors
def show?
user.reader || user.id == record.user_id
end
def update?
user.id == record.user_id
end
def destroy?
user.id == record.user_id
end
private
def allow_editors
allow! if user.editor
end
end
Scopes
Another Action Policy feature that deserves our attention is scoping
. Scopes filter data depending on any authorization rules you've set.
Using our blog app as an example, let's say we want to apply the following rules to the posts index action:
- List all posts for all users with the "editor" role
- List only posts that a user has created if they have the "author" role
Without using any Action Policy authorization, the posts controller index action looks like any generic index action:
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
...
def index
@posts = Post.all
end
...
end
We'll need to utilize Action Policy scoping to refactor this action and apply the outlined access rules. Scoping rules are defined within a policy class and applied in the respective controller using the authorized_scope
or authorized
methods.
First modify the Post policy, like so:
# app/policies/posts_policy.rb
class PostPolicy < ApplicationPolicy
...
relation_scope do |scope|
if user.editor?
scope
end
end
end
relation_scope(:own) do |scope|
scope.where(user: user)
end
end
...
end
Then the posts controller's index action, as shown below:
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
...
def index
@posts = authorized_scope(Post, type: :relation, as: :own)
end
...
end
Caching in Action Policy for Ruby and Rails
Action Policy is a performant authorization library, partly thanks to its efficient use of caching.
It has several cache layers for you to leverage, including memoization and external caching.
Memoization
Consider a situation where the same rule is called several times on an object instance. For example, let's say we need to load all comments associated with a post within the index
action:
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
...
def index
@posts = authorized_scope(Post.includes(comments), ...)
end
...
end
Now, imagine there's an "edit" link for every comment a post has within the index view. As you can see, this is a resource-intensive undertaking since we need to check if the current user is allowed to first access the post index, and then edit a post's comments. If a post has multiple comments, this would mean loading the authorization policy multiple times.
In a situation like this, Action Policy will re-use the required policy instance — specifically, the record.policy_cache_key
— as one of the identifiers in the local store.
This kind of caching works well for short-lived requests, but if you need to cache resource-intensive rules that will be persisted across requests, using an external cache store is a better option.
Using an External Cache Store
If you need to run access control rules that utilize complex database queries, for example, you can use an external cache store such as Redis. Your rules cache will be made available across requests. You just need to remember to explicitly define which rules to cache within the policy class:
# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
cache :index?
def show?
# some complex database heavy rules...
end
....
end
And configure the cache store for your app:
# config/application.rb
Rails.application.configure do |config|
config.action_policy.cache_store = :redis_cache_store
end
Quick tip: There's a lot more to this. Dig into the Action Policy caching documentation for more information.
Aliases in Action Policy for Rails
An alias is an alternative way to name policies so that they make more sense.
Let's check out an example using our blog app. Consider this Post policy:
# app/policies/post_policy.rb
class PostPolicy < ApplicationPolicy
alias_rule :destroy?, :update?, to: :manage_post?
...
def manage_article?
user.editor || user.id == record.user_id
end
...
end
Here, we combine the update?
and destroy?
rules into one alias called manage_post?
.
Then we use it in the controller, like so:
# app/controllers/posts_controller.rb
class PostsController < ApplicationController
...
def update
authorize! :manage_post?, @post
...
end
# DELETE /posts/1 or /posts/1.json
def destroy
authorize! :manage_post?, @post
...
end
...
end
Finally, let's quickly look at how to handle unauthorized access.
Handling Unauthorized Access in a Ruby and Rails App
If a user tries to access a resource they shouldn't, an ActionPolicy::Unauthorized
error is raised.
You need to explicitly handle this error in your app's ApplicationController
, like so:
# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
rescue_from ActionPolicy::Unauthorized do
redirect_to root_path, alert: 'Access denied.'
end
end
And that's it!
Wrapping Up
In this post, we explored advanced Action Policy features, including pre-checks, scopes, caching, aliases, and finally, handling unauthorized access.
From basic rules to complex conditional scenarios, Action Policy has everything you need to handle almost any authorization scenario. Use this library in your next project and see how powerful it is.
Happy coding!
P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!
Top comments (0)