Skip to content

Latest commit

 

History

History

docs

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
assets
assets
 
 
.nojekyll
.nojekyll
 
 
CNAME
CNAME
 
 
README.md
README.md
 
 
_sidebar.md
_sidebar.md
 
 
aliases.md
aliases.md
 
 
authorization_context.md
authorization_context.md
 
 
behaviour.md
behaviour.md
 
 
caching.md
caching.md
 
 
custom_lookup_chain.md
custom_lookup_chain.md
 
 
custom_policy.md
custom_policy.md
 
 
debugging.md
debugging.md
 
 
decorators.md
decorators.md
 
 
favicon.ico
favicon.ico
 
 
graphql.md
graphql.md
 
 
i18n.md
i18n.md
 
 
index.html
index.html
 
 
instrumentation.md
instrumentation.md
 
 
lookup_chain.md
lookup_chain.md
 
 
namespaces.md
namespaces.md
 
 
non_rails.md
non_rails.md
 
 
pre_checks.md
pre_checks.md
 
 
pundit_migration.md
pundit_migration.md
 
 
quick_start.md
quick_start.md
 
 
rails.md
rails.md
 
 
reasons.md
reasons.md
 
 
scoping.md
scoping.md
 
 
testing.md
testing.md
 
 
writing_policies.md
writing_policies.md
 
 

README.md

Gem Version Build

Action Policy

Authorization framework for Ruby and Rails.
Composable. Extensible. Performant.

What is it?

Authorization is an act of giving someone official permission to do something (to not be confused with authentication).

Action Policy provides flexible tools to build an authorization layer for your application.

Authorization layer

NOTE: Action Policy does not force you to use a specific authorization model (i.e., roles, permissions, etc.) and does not provide one. It only answers a single question: How to verify access?

Where to go from here?

Project State

The project is being used in production since mid 2018. Major features have been implemented, API has been stabilized. Check out our development board to see what's coming next.

History

Action Policy gem is an extraction-kind of a library. Most of the code has been used in production for several years in different Evil Martians projects.

We have decided to collect all our authorization techniques and pack them into a standalone gem–and that is how Action Policy was born!

What about the existing solutions?

Why did we decide to build our own authorization gem instead of using the existing solutions, such as Pundit and CanCanCan?

TL;DR they didn't solve all of our problems.

Pundit has been our framework of choice for a long time. Being too dead-simple, it required a lot of hacking to fulfill business logic requirements.

These hacks later became Action Policy (initially, we even called it "Pundit, re-visited").

We also took a few ideas from CanCanCan—such as default rules and rule aliases.

It is also worth noting that Action Policy (despite having a Railsy name) is designed to be Rails-free. On the other hand, it contains some Rails-specific extensions and seamlessly integrates into the framework.

So, what are the main reasons to consider Action Policy as your authorization tool?

  • Performance: multiple caching strategies out-of-the-box make authorization overhead as small as possible–especially useful when your rules involve DB queries; you can also monitor the performance and detect the bottlenecks using the built-in instrumentation features.

  • Composition & Customization: use only the features you need or easily extend the functionality–it's just Ruby classes and modules, (almost) zero magic! And you can add authorization anywhere in your code, not only in controllers.

  • Code Organization: use namespaces to organize your policies (for example, when you have multiple authorization strategies); add pre-checks to make rules more readable and better express your business-logic.

  • ...and more: testability, i18n integrations, actionable errors.

Learn more about the motivation behind the Action Policy and its features by watching this RailsConf talk.

Resources

Sponsored by Evil Martians