#386 Authorization from Scratch Part 2 pro

In regards to the use of Array(controllers) to enumerate over potentially singular things, I have been using another technique I saw at http://www.rubyinside.com/21-ruby-tricks-902.html #18: [*controllers].each... Is there anything wrong with that form that I don't know about?

Very nice! Especially liked that it was all done with testing.

Not sure that I like putting permissions definitions into separate files though. I would expect to see those directly in controllers and models defined with class method calls. The same way as attr_accessible is used - right from the model - for example. But maybe I just don't see all the benefits of using separate files yet, need to play with the code first I guess. Or maybe it's just a matter of taste :)

Anyway, great learning material!

Is there a way to whitelist for any actions within a controller using this method?

In the method you suggested in part 1, we did this:

return true if controller == "pages"

A new-bee here. Can someone kindly explain what the 'resource' argument refers to. I am reading the code and I know what 'controller' and 'action' are referring to, but I am clueless about the 'resource' being passed as an argument stands for.

Many thanks.

A link to the code on railscast repo: http://bit.ly/TceGen
app/models/permissions/base_permission.rb

module Permissions

  class BasePermission

   def allow?(controller, action, resource = nil)
   end

   def allow_param(resources, attributes)
   end

 end

 def permit_params!(params)
 end

end

This is most mind-expanding episode I've watched so far. I can't even get myself to code today because I keep thinking of ways to implement this into my project. It's possible I could remove dozens of files and lots of complexity, while improving the testability with this method.

There's nothing like having the author of cancan explain authorization. Thank!

any ideas how to implement the accessible_by for the index action?

like with cancan:
@projects = Project.accessible_by(current_ability)

# This module adds the accessible_by class method to a model. It is included in the model adapters.
# An alternative action can optionally be passed as a second argument.
#
# @articles = Article.accessible_by(current_ability, :update)
#
# Here only the articles which the user can update are returned.

  def accessible_by(ability, action = :index)
    ability.model_adapter(self, action).database_records
  end

Permissions.permission_for(user) shows nearly what i'm looking for, but it doesn't work for the index action where a the customer_id matches.

  allow_action :cabinets, [ :index, :new, :create, :edit, :update ] do |cabinet|
    cabinet.customer_id == user.customer_id

Can anyone point me in the right direction? I want to allow a user to only show, edit, update, or destroy their own user resource? I've implemented the @current_user caching from rails cast #274 Remember Me & Reset Password

private 
  def current_user
    @current_user ||= User.find_by_auth_token!(cookies[:auth_token]) if cookies[:auth_token]
  end
def current_resource
    nil
  end
  
  def authorize
    if current_permission.allow?(params[:controller], params[:action], current_resource)
      current_permission.permit_attr! params
    else
      if current_user
        flash[:alert] = 'Not Authorized'
        redirect_to home_path
      else
        session[:protected_page] = request.fullpath
        flash[:alert] = 'Please Login'
        redirect_to root_url
      end
    end
  end

module Permissions
  class MemberPermission < BasePermission
    def initialize(user)
      allow :sessions,        [:new,:create,:destroy]
      allow :password_resets, [:new,:create,:edit,:update]
      allow :users,           [:new,:create]
      allow :users,           [:show,:edit,:update,:destroy] do |current_user|
        current_user.id == user.id
      end
      allow :interests,       [:new, :create]
      allow :interests,       [:edit, :update, :destroy] do |interest| 
        interest.user_id == user.id 
      end
      allow_attr :user,       [:email, :zip_code]
    end
  end
end

I get caught in an infinite redirect loop when a normal user tries to show their own user profile. Any tips or suggestions would be appreciated. Mahalo

How do you adapt when authorization depends on a parent model when the resource is not a singleton? Say topics#index can only be accessed if the forum is public. The topics#index returns an array, not a singleton, so we can't call topics.forum.private?

What would be really helpful is how to extend this to handle nested resources... Has anyone extended this to use nested resources and have some guidance to share?

How would you use this authorisation logic with Devise?

I tried:

module Permissions
  class GuestPermission < BasePermission
    def initialize
      allow :devise_sessions, [:new, :create, :destroy]
      allow :sessions, [:new, :create, :destroy]
      allow :user_sessions, [:new, :create, :destroy]
    end
  end
end

But a guest is never able to login :(

I too would be very interested in seeing how to tackle authorization on an index page where the user should only see a list of appropriate objects.

Do you have plans to make another video or perhaps just show some example code for how this might be done?

I don't understand this line in the allow? method.

allowed && (allowed == true || resource && allowed.call(resource))

Could someone break it down for me please?

class Permission
def initialize(current_user)
allow :index_page, [:index]
allow :static_pages, [:about, :contact]
allow :sessions, [:new, :create, :destroy]
allow :users, [:edit, :update]

def allow_all
  @allow_all = true
end

def allow(controllers, actions)
  @allowed_actions ||= {}
  Array(controllers).each do |controller|
    Array(actions).each do |action|
      @allowed_actions[[controller.to_s, action.to_s]] = true
    end
  end
end

end
end

but there is something wrong
NoMethodError in PrimaryPagesController#index

undefined method `allow' for #Permission:0x007fcaee54a310
Rails.root: /Users/freshlhy/rails_projects/first_app

Application Trace | Framework Trace | Full Trace
app/models/permission.rb:3:in initialize'
app/controllers/application_controller.rb:12:innew'
app/controllers/application_controller.rb:12:in current_permission'
app/controllers/application_controller.rb:20:inauthorize'

How is it possible to use that with nested attributes (forms). I have my models defined as follows:

class Timesheet < ActiveRecord::Base
  belongs_to :user
  has_many :activities, dependent: :destroy, inverse_of: :timesheet
  has_many :time_entries, through: :activities
  accepts_nested_attributes_for :activities, allow_destroy: true
end

class Activity < ActiveRecord::Base
  belongs_to :timesheet, inverse_of: :activities
  belongs_to :task
  has_many :time_entries, order: :workdate, dependent: :destroy, inverse_of: :activity
  accepts_nested_attributes_for :time_entries, allow_destroy: true, reject_if: proc { |a| a[:worktime].blank? }
end


class TimeEntry < ActiveRecord::Base
  belongs_to :activity, :inverse_of => :time_entries
  validates :worktime, presence: true, inclusion: { in: [0.5, 1] }       
  validates_presence_of :activity     
end

Actually it does not work. As far I could see at Ryan's strong_parameters rails casts github https://github.com/railscasts/371-strong-parameters, he managed to do that (not very dynamically as he said and only for one post). In my case I have 1 or more activity with 7 time_entries each. Any idea how to do that? Thank you.

In the latest version of rspec, I'm getting errors like:

  1) Permission as guest allows sessions
     Failure/Error: should allow(:sessions, :new)
     ArgumentError:
       wrong number of arguments (2 for 1)
     # ./spec/models/permission_spec.rb:20:in `block (3 levels) in <top (required)>'
     # -e:1:in `<main>'

It seems the matcher is not valid anymore?

RSpec::Matchers.define :allow do |*args|
  match do |permission|
    permission.allow?(*args).should be_true
  end
end

How would you rewrite it so that it works with the latest rspec?

After implementing that authorization solution, many of my controllers specs started failing because they are not authorized to run without the proper permission. How can I fake permission in a controller test to fix this problem?

While Ryan is on his Sabbatical, I think it important to keep some of this information up-to-date with the changes. Ryan developed a well-deserved reputation and his RailsCasts are referenced just about anywhere you can google a rails problem/solution.

As such, I want to comment on a couple of things regarding this episode.

The strong_parameters gem is automatically implemented in this episode. This is confusing because the docs for s_p shows controller-level checking, which has now become the standard for all Rails 4 apps.

You may notice that there isn't a method permitted_params inside the application_controller. All whitelisting logic has been moved to the application controller via the authorize method, which calls current_permission. All strong_parameters checking is now handled by base_permission.rb inside the permit_params!(params) method and delegated to each of the permission classes - Admin, Member and Guest.

I found it very advantageous to rename some of Ryan's code. In the video, he recommends renaming the allow method to allow_action. DO THIS. Also, I took the liberty of renaming the allow_param method to allow_attribute, since that is what is being allowed and it removes identity confusion with the params hash.

All-in-all, this is a great starting point for any Rails-based app. All you need to do is fork the code from GitHub, include the rename gem to change the name of the app, and start building your models. For each model you include, go back and whitelist the appropriate attributes (model fields) with the appropriate authorizations (admin, guest, etc.) Voila! Instant authorization including mass-assignment protection.

Now, just pop on over to RC#250 (revised) and roll your own authentication. Both episodes merge without problems. Now you have a fully functional template for building just about anything.

How can we extends this solution to query ActiveRecord? Trying to keep the solution DRY.

So I would like to be able to use that logic to List(index) a resource and passing the Authorization parameters to ActiveRecord which would return only the authorized resources.

Cheers,

I came back to this solution while I was trying to teach myself code optimization and refactoring.

I tried as an exercise refactoring class MemberPermission < BasePermission to class MemberPermission < GuestPermission, seeing as how much of the static pages logic, etc. is being duplicated. I thought that is Members could inherit all the permissions of a guest, then it would be better.

However, the filter chain halts as :authorize redirects in an infinite loop. Generally, this means that a permission hasn't been defined for that user and it's trying to redirect to static#home.

I was wondering if anyone has any insight on this? I'll post to Stack as well..

The Stack question, and hopefully answer...

Thanks for this