The problem in testing a create action is that the object is not already created. Thus a class policy initialisation could state:
def initialize(user, promotion)
#user = user
#promotion = promotion
end
with #shop = #promotion.shop_id added to the edit/update/delete policy actions.
However, the user may have a role within that shop that allows it to do some privileged actions, such as create ...
def shopmanager
#roleshopuser ||= Roleshopuser.where(['user_id = ? AND shop_id = ? AND role_id IN (?)', user.id, #shop, [1,2]]).first
end
note: this functions properly on edit/update/destroy actions, thus validating the testing fixtures
As the initialisation process indicates, the promotion requires a shop_id and is thus a submitted param to the create action. Therefore the controller action is defined as (with the puts confirming the presence of the parameter):
def create
puts params[:promotion][:shop_id]
#target_shop = params[:promotion][:shop_id]
#promotion = Promotion.new(promotion_params)
authorize #promotion
and the policy adapted accordingly
def create?
#shop = #target_shop
puts user.id
puts user.admin?
puts shopmanager.nil?
!user.nil? && (user.admin? || !shopmanager.nil?)
end
again the puts do indicate that there is proper handling of the attributes and method
The test however fails
test "should create promotion" do
#shop = shops(:three_4)
#shopusers.each do |user|
sign_in user
#shopusers.each do |user|
sign_in user
assert_difference('Promotion.count') do
post promotions_url, params: { promotion: { name: (#promotion.name + user.id.to_s), shop_id: #promotion.shop_id [...]
end
assert_redirected_to promotion_url(Promotion.last)
end
sign_out user
end
end
From the puts data, the policy runs on user.admin?, but the policy fails where true is returned for the next user fixture when running method shopmanager.nil? (admin is false). As the edit/update functions work with the same fixtures, this points to an error in the policy for create.
What is it?
There is a path through this as indicated in documentation.
For the above case, the initialization requires modification to handle additional elements
attr_reader :user, :promotion, :shop
def initialize(context, promotion)
#user = context.user
#shop = context.shop
#promotion = promotion
end
the Class-specific controller needs amending to pass on the context, adjusted for whether the object already exists or not.
class PromotionsController < ApplicationController
include Pundit
private
def pundit_user
if #promotion.blank?
shop = params[:promotion][:shop_id]
else
shop = #promotion.shop_id
end
CurrentContext.new(current_user, shop)
end
Then the policy can check if the user is a manager of the shop.
Related
I have a table of users with enum user_type [Manager, Developer, QA]. Currently, I'm handling sign in using Devise and after login I'm using the following logic to display the appropriate webpage:
class HomeController < ApplicationController
before_action :authenticate_user!
def index
if current_user.manager?
redirect_to manager_path(current_user.id)
end
if current_user.developer?
redirect_to developer_path(current_user.id)
end
if current_user.quality_assurance?
redirect_to qa_path(current_user.id)
end
end
end
I want to use pundit gem to handle this. From the documentation, it transpired that this logic will be delegated to policies but I can't figure out how. Can somebody help me in implementing pundit in my project?
This is my users table:
I have created a user_policy but its mostly empty:
class UserPolicy < ApplicationPolicy
class Scope < Scope
def resolve
scope.all
end
end
end
User model:
You want to use Pundit to authorize a user, as in check if that user should be allowed to visit a controller action. If the user is not authorized for a specific action it raises a Pundit::NotAuthorizedError
You can check if a user is allowed to perform an action in the pundit policy, in which you have access to record (the instance thats passed to authorize) and user. So assuming you have a Flat Model, where only the owner can edit the Flat you might do this:
# flats_policy.rb
def edit?
record.user == user
end
Now lets say you also want to allow admins to edit you might do this
# flats_policy.rb
def owner_or_admin?
record.user == user || user.admin # where admin is a boolean
end
def edit?
owner_or_admin?
end
and the controller:
# flats_controller.rb
def edit
#flat = Flat.find(params[:id])
authorize #flat
# other code here
end
Now the index action is the odd one out because you would essentially have to call authorize on each instance, so the way Pundit handles this is with the Scope:
# flats_policy.rb
class Scope < Scope
def resolve
scope.all
end
end
and a corresponding index action might look like:
def index
#flats = policy_scope(Flat) # note that we call the model here
end
So lets say a user can only see flats that he/she owns:
# flats_policy.rb
class Scope < Scope
def resolve
scope.where(user: user)
end
end
and if admins can see all flats:
# flats_policy.rb
class Scope < Scope
def resolve
if user.admin
scope.all
else
scope.where(user: user)
end
end
end
In any case if the user is not allowed to perform an action you can rescue from the error like so:
# application_controller
rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized
def user_not_authorized
flash[:alert] = "You are not authorized to perform this action."
redirect_to(root_path)
end
I guess you could do some dirty redirecting here, as in send admins to an admins_root_path, users to a default_root_path and so on...
On a final note, since this post is already too long you can check a policy in the view like this:
<% if policy(restaurant).edit? %>
You can see me if you have edit rights
<% end %>
Apparently, you can't access the params hash in a Pundit policy. It makes sense that they want to expose as little information to the policies as possible. But one use case I'm running into, which I would think would be quite common, is to check that the current_user is the user from the params.
So here's my new action in my controller:
class ReviewsController < ApplicationController
...
def new
#user = User.friendly.find(params[:user_id])
unless current_user.admin? || current_user.id == #user.id
flash[:alert] = 'Access denied.'
redirect_to root_url
end
#review = #user.reviews.build
end
...
end
So here, I'm saying to authorize if the user is an admin, or the current user is the same as the one in the URL. Otherwise, the user with the id of 2 could go to /users/1/reviews/new.
There doesn't seem to be any way to handle this in the policy, because I can't pass the params[:user_id] into the policy.
Is there a way to handle this authorization scheme from a Pundit policy, rather than handling auth logic in my controller?
Not sure if this question is out of date.
When pundit does the authorization in the controller, it will pass two objects. One is record and another is current_user. But you only need to provide the record when you call the authorize method, current_user will be passed automatically.
#authorize(record, query = nil) ⇒ true
In your case, when you call authorize(#user, :new?), in your policy, #user will be referenced as record, and current_user will be referenced as user.
Therefore, in your policy:
class UserPolicy < ApplicationPolicy
def new?
user.admin? || record == user
end
end
And you can check the policy in your controller:
class ReviewsController < ApplicationController
...
def new
#user = User.friendly.find(params[:user_id])
authorize(#user, :new?)
#review = #user.reviews.build
end
...
end
controller show action
def show
#batch = Batch.find(params[:id])
#batch_id = #batch.id
authorize #batch
end
pundit policy
def show?
puts #batch_id
if !current_user.nil? && (current_user.role?('Student')) || (current_user.role?('Administrator')) || (current_user.role?('SupportSpecialist')) || (current_user.role?('Instructor'))
true
else
false
end
end
I am getting nil when I puts #batch_id, how can I get that value in policy action
Your controller:
def show
#batch = Batch.find(params[:id])
#batch_id = #batch.id
authorize #batch
end
Your policy file might be:
class BatchPolicy
attr_reader :user, :record
def initialize(user, record)
#user = user
#record = record
end
def show?
true if record ... // record will be equal #batch
end
end
If you want additional context, then you must know:
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. If you find yourself needing more context than that, consider whether you are authorizing the right domain model, maybe another domain model (or a wrapper around multiple domain models) can provide the context you need.
Pundit does not allow you to pass additional arguments to policies for precisely this reason.
There you can learn about it from the horse's mouth.
I'm trying to set up gradual engagement in my utility app which people can use without registering e.g. notepad.cc and jsfiddle.net and I plan to create a guest user (with Devise) for the user when he 'writes' to the app.
I found this guide on the Devise wiki https://github.com/plataformatec/devise/wiki/How-To:-Create-a-guest-user which shows how to create a guest user for the duration of the browser session. What I want is for the user to continue using the same guest account in subsequent visits, until he signs up, maybe when I introduce subscription plans for more features.
How can I modify what's in the guide to make this possible?
Code in the guide linked above:
# file: app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
protect_from_forgery
# if user is logged in, return current_user, else return guest_user
def current_or_guest_user
if current_user
if session[:guest_user_id]
logging_in
guest_user.destroy
session[:guest_user_id] = nil
end
current_user
else
guest_user
end
end
# find guest_user object associated with the current session,
# creating one as needed
def guest_user
User.find(session[:guest_user_id].nil? ? session[:guest_user_id] = create_guest_user.id : session[:guest_user_id])
end
# called (once) when the user logs in, insert any code your application needs
# to hand off from guest_user to current_user.
def logging_in
end
private
def create_guest_user
u = User.create(:name => "guest", :email => "guest_#{Time.now.to_i}#{rand(99)}#email_address.com")
u.save(false)
u
end
end
And using it in the controller:
#thing.user = current_or_guest_user
#thing.save
After some yak-shaving I've managed to get it to work. Here's the working code:
class ApplicationController < ActionController::Base
protect_from_forgery
# if user is logged in, return current_user, else return guest_user
def current_or_guest_user
if current_user
if cookies[:uuid]
logging_in # Look at this method to see how handing over works
guest_user.destroy # Stuff have been handed over. Guest isn't needed anymore.
cookies.delete :uuid # The cookie is also irrelevant now
end
current_user
else
guest_user
end
end
# find guest_user object associated with the current session,
# creating one as needed
def guest_user
User.find_by_lazy_id(cookies[:uuid].nil? ? create_guest_user.lazy_id : cookies[:uuid])
end
# called (once) when the user logs in, insert any code your application needs
# to hand off from guest_user to current_user.
def logging_in
# What should be done here is take all that belongs to user with lazy_id matching current_user's uuid cookie... then associate them with current_user
end
private
def create_guest_user
uuid = rand(36**64).to_s(36)
temp_email = "guest_#{uuid}#email_address.com"
u = User.create(:email => temp_email, :lazy_id => uuid)
u.save(:validate => false)
cookies[:uuid] = { :value => uuid, :path => '/', :expires => 5.years.from_now }
u
end
end
I will accept another answer if you can show me a better way to do this.
The above solution works great.
Don't forget to setuphelper_method :current_or_guest_user to make the method accessible in views. Took me some time to figure out.
I have 3 tables
items (columns are: name , type)
history(columns are: date, username, item_id)
user(username, password)
When a user say "ABC" logs in and creates a new item, a history record gets created with the following after_create filter.
How to assign this username ‘ABC’ to the username field in history table through this filter.
class Item < ActiveRecord::Base
has_many :histories
after_create :update_history
def update_history
histories.create(:date=>Time.now, username=> ?)
end
end
My login method in session_controller
def login
if request.post?
user=User.authenticate(params[:username])
if user
session[:user_id] =user.id
redirect_to( :action=>'home')
flash[:message] = "Successfully logged in "
else
flash[:notice] = "Incorrect user/password combination"
redirect_to(:action=>"login")
end
end
end
I am not using any authentication plugin. I would appreciate if someone could tell me how to achieve this without using plugin(like userstamp etc.) if possible.
Rails 5
Declare a module
module Current
thread_mattr_accessor :user
end
Assign the current user
class ApplicationController < ActionController::Base
around_action :set_current_user
def set_current_user
Current.user = current_user
yield
ensure
# to address the thread variable leak issues in Puma/Thin webserver
Current.user = nil
end
end
Now you can refer to the current user as Current.user
Documentation about thread_mattr_accessor
Rails 3,4
It is not a common practice to access the current_user within a model. That being said, here is a solution:
class User < ActiveRecord::Base
def self.current
Thread.current[:current_user]
end
def self.current=(usr)
Thread.current[:current_user] = usr
end
end
Set the current_user attribute in a around_filter of ApplicationController.
class ApplicationController < ActionController::Base
around_filter :set_current_user
def set_current_user
User.current = User.find_by_id(session[:user_id])
yield
ensure
# to address the thread variable leak issues in Puma/Thin webserver
User.current = nil
end
end
Set the current_user after successful authentication:
def login
if User.current=User.authenticate(params[:username], params[:password])
session[:user_id] = User.current.id
flash[:message] = "Successfully logged in "
redirect_to( :action=>'home')
else
flash[:notice] = "Incorrect user/password combination"
redirect_to(:action=>"login")
end
end
Finally, refer to the current_user in update_history of Item.
class Item < ActiveRecord::Base
has_many :histories
after_create :update_history
def update_history
histories.create(:date=>Time.now, :username=> User.current.username)
end
end
The Controller should tell the model instance
Working with the database is the model's job. Handling web requests, including knowing the user for the current request, is the controller's job.
Therefore, if a model instance needs to know the current user, a controller should tell it.
def create
#item = Item.new
#item.current_user = current_user # or whatever your controller method is
...
end
This assumes that Item has an attr_accessor for current_user.
The Rails 5.2 approach for having global access to the user and other attributes is CurrentAttributes.
If the user creates an item, shouldn't the item have a belongs_to :user clause? This would allow you in your after_update to do
History.create :username => self.user.username
You could write an around_filter in ApplicationController
around_filter :apply_scope
def apply_scope
Document.where(:user_id => current_user.id).scoping do
yield
end
This can be done easily in few steps by implementing Thread.
Step 1:
class User < ApplicationRecord
def self.current
Thread.current[:user]
end
def self.current=(user)
Thread.current[:user] = user
end
end
Step 2:
class ApplicationController < ActionController::Base
before_filter :set_current_user
def set_current_user
User.current = current_user
end
end
Now you can easily get current user as User.current
The Thread trick isn't threadsafe, ironically.
My solution was to walk the stack backwards looking for a frame that responds to current_user. If none is found it returns nil. Example:
def find_current_user
(1..Kernel.caller.length).each do |n|
RubyVM::DebugInspector.open do |i|
current_user = eval "current_user rescue nil", i.frame_binding(n)
return current_user unless current_user.nil?
end
end
return nil
end
It could be made more robust by confirming the expected return type, and possibly by confirming owner of the frame is a type of controller...