elabs/pundit: Minimal authorization through OO design and pure Ruby classes - 0 views
-
The class implements some kind of query method
-
Pundit will call the current_user method to retrieve what to send into this argumen
-
put these classes in app/policies
- ...49 more annotations...
-
in leveraging regular Ruby classes and object oriented design patterns to build a simple, robust and scaleable authorization system
-
map to the name of a particular controller action
-
In the generated ApplicationPolicy, the model object is called record.
-
record
-
authorize
-
authorize would have done something like this: raise "not authorized" unless PostPolicy.new(current_user, @post).update?
-
pass a second argument to authorize if the name of the permission you want to check doesn't match the action name.
-
you can chain it
-
authorize returns the object passed to it
-
the policy method in both the view and controller.
-
have some kind of view listing records which a particular user has access to
-
ActiveRecord::Relation
-
Instances of this class respond to the method resolve, which should return some kind of result which can be iterated over.
-
scope.where(published: true)
-
-
use this class from your controller via the policy_scope method:
-
PostPolicy::Scope.new(current_user, Post).resolve
-
policy_scope(@user.posts).each
-
This method will raise an exception if authorize has not yet been called.
-
verify_policy_scoped to your controller. This will raise an exception in the vein of verify_authorized. However, it tracks if policy_scope is used instead of authorize
-
need to conditionally bypass verification, you can use skip_authorization
-
skip_policy_scope
-
Having a mechanism that ensures authorization happens allows developers to thoroughly test authorization scenarios as units on the policy objects themselves.
-
Pundit doesn't do anything you couldn't have easily done yourself. It's a very small library, it just provides a few neat helpers.
-
all of the policy and scope classes are just plain Ruby classes
-
rails g pundit:policy post
-
define a filter that redirects unauthenticated users to the login page
-
fail more gracefully
-
raise Pundit::NotAuthorizedError, "must be logged in" unless user
-
having rails handle them as a 403 error and serving a 403 error page.
-
config.action_dispatch.rescue_responses["Pundit::NotAuthorizedError"] = :forbidden
-
with I18n to generate error messages
-
retrieve a policy for a record outside the controller or view
-
define a method in your controller called pundit_user
-
Pundit strongly encourages you to model your application in such a way that the only context you need for authorization is a user object and a domain model that you want to check authorization for.
-
Pundit does not allow you to pass additional arguments to policies
-
authorization is dependent on IP address in addition to the authenticated user
-
create a special class which wraps up both user and IP and passes it to the policy.
-
set up a permitted_attributes method in your policy
-
policy(@post).permitted_attributes
-
permitted_attributes(@post)
-
Pundit provides a convenient helper method
-
permit different attributes based on the current action,
-
If you have defined an action-specific method on your policy for the current action, the permitted_attributes helper will call it instead of calling permitted_attributes on your controller
-
If you don't have an instance for the first argument to authorize, then you can pass the class
-
restart the Rails server
-
Given there is a policy without a corresponding model / ruby class, you can retrieve it by passing a symbol
-
after_action :verify_authorized
-
It is not some kind of failsafe mechanism or authorization mechanism.
-
Pundit will work just fine without using verify_authorized and verify_policy_scoped
