makandra/consul

Scope-based authorization for Ruby on Rails.

consul's Issues

Can't skip :check_power action in v1.0.3

We have a complex controller structure in which a power is defined at one level, and in a descendant it is skipped. For example:

class AssignmentsController < ApplicationController
  include Consul::Controller
  current_power do
    Power.new(current_user, params[:ministry_id])
  end

  power :assignments, map: {
    [:show] => :showable_assignments,
    [:update] => :updateable_assignments,
  }, as: :assignment_scope

  ...
end

class SystemsAssignmentsController < AssignmentsController
  skip_around_action :with_current_power
  skip_before_action :check_power, raise: false

  ...
end

In v1.0.3, the name of the before_action :check_power was removed so that it is no longer named, and therefore we can no longer skip it. Can this be fixed somehow?

Namespace support

Is there a good way to handle a situation where you have different powers for the same objects in different namespaces. For instance we have an Admin namespace that has User powers that differ entirely from the User powers in the main namespace.

How to organize Power file?

I have a rather large project with a lot of models and I am considering moving to Consul from CanCan.

How do you usually organize the Power file in such a project? Split it into multiple files?

Singular object checks and AR 4

Hey Henning,

Sorry to bug again - I'd patch this myself but I'm not sure how you'd like to do it and it's something that I think others will see benefit from. I see that right now consul is checking in Util.collection? if something is an Array or Set, but ActiveRecord scopes return CollectionProxy objects which for all intents and purposes behave the same as any other collection. The end result is that I can't use the singular power checks (i.e. power.user?(user_object)) out of the box and have to define them manually. It seems that they check this before trying to call Enumerable#include?, but there may be something else that I'm not aware of that this method's used for.

Take a look at this stack trace:

2.0.0-p451 :005 > p.user_account? Accounts::Account.first
  Accounts::Account Load (0.8ms)  SELECT  "accounts_accounts".* FROM "accounts_accounts"   ORDER BY "accounts_accounts"."id" ASC LIMIT 1
Consul::NoCollection: can only call #include_object? on a collection, but power was of type ActiveRecord::Associations::CollectionProxy
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/consul-0.11.2/lib/consul/power.rb:40:in `default_include_object?'
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/consul-0.11.2/lib/consul/power.rb:123:in `block in define_power'
    from (irb):5
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/railties-4.1.1/lib/rails/commands/console.rb:90:in `start'
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/railties-4.1.1/lib/rails/commands/console.rb:9:in `start'
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/railties-4.1.1/lib/rails/commands/commands_tasks.rb:69:in `console'
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/railties-4.1.1/lib/rails/commands/commands_tasks.rb:40:in `run_command!'
    from /Users/jriley/.rvm/gems/ruby-2.0.0-p451/gems/railties-4.1.1/lib/rails/commands.rb:17:in `<top (required)>'
    from bin/rails:6:in `require'
    from bin/rails:6:in `<main>'

This is generated from a power definition like the following:

power :user_accounts do
user.accounts
end

I prefer not to make these into arrays explicitly as I often scope them down further, so being able to interact with the CollectionProxy is handy. Any thoughts on how you'd like to approach this to make the singular query method work on a CollectionProxy? I figure you probably don't want to include a dependency on ActiveRecord in your gem, so perhaps rather than checking with an is_a? on the collection, consul could check if it responds to include? or has Enumerable in its ancestry or something similar?

Cheers!
James

Intermittent js spec failures caused by NoMethodError in consul/guard.rb

Hiya,

I'm having intermittent spec failures when using either selenium or poltergeist - can't say I'm 100% sure why, however I'm getting the following stack trace every time they bomb out. Any idea what might be going on here? As far as I can tell it seems like my controller's returning nil when current_power is called, but I don't see any reason why. This only happens selenium/poltergeist specs, and it happens on about a quarter of requests. I've never once seen it logged in prod or dev. Any pointers or ideas would be appreciated!

Edit: This cropped up after an upgrade to Rails 4.0.4 from 3.2. It worked flawlessly in 3.2.

Cheers,
James

---

Completed 500 Internal Server Error in 16ms

NoMethodError (undefined method `include_power!' for nil:NilClass):
  consul (0.11.1) lib/consul/guard.rb:71:in `ensure!'
  consul (0.11.1) lib/consul/controller.rb:77:in `block (2 levels) in <module:InstanceMethods>'
  consul (0.11.1) lib/consul/controller.rb:76:in `each'
  consul (0.11.1) lib/consul/controller.rb:76:in `block in <module:InstanceMethods>'
  activesupport (4.0.4) lib/active_support/callbacks.rb:438:in `block in _run__3979056852270749029__process_action__callbacks'
  activesupport (4.0.4) lib/active_support/callbacks.rb:212:in `block in _conditional_callback_around_57'
  consul (0.11.1) lib/consul/controller.rb:93:in `call'
  consul (0.11.1) lib/consul/controller.rb:93:in `with_current_power'
  activesupport (4.0.4) lib/active_support/callbacks.rb:211:in `_conditional_callback_around_57'
  activesupport (4.0.4) lib/active_support/callbacks.rb:403:in `_run__3979056852270749029__process_action__callbacks'
  activesupport (4.0.4) lib/active_support/callbacks.rb:80:in `run_callbacks'
  actionpack (4.0.4) lib/abstract_controller/callbacks.rb:17:in `process_action'
  actionpack (4.0.4) lib/action_controller/metal/rescue.rb:29:in `process_action'
  actionpack (4.0.4) lib/action_controller/metal/instrumentation.rb:31:in `block in process_action'
  activesupport (4.0.4) lib/active_support/notifications.rb:159:in `block in instrument'
  activesupport (4.0.4) lib/active_support/notifications/instrumenter.rb:20:in `instrument'
  activesupport (4.0.4) lib/active_support/notifications.rb:159:in `instrument'
  actionpack (4.0.4) lib/action_controller/metal/instrumentation.rb:30:in `process_action'
  actionpack (4.0.4) lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
  activerecord (4.0.4) lib/active_record/railties/controller_runtime.rb:18:in `process_action'
  actionpack (4.0.4) lib/abstract_controller/base.rb:136:in `process'
  actionpack (4.0.4) lib/abstract_controller/rendering.rb:44:in `process'
  actionpack (4.0.4) lib/action_controller/metal.rb:195:in `dispatch'
  actionpack (4.0.4) lib/action_controller/metal/rack_delegation.rb:13:in `dispatch'
  actionpack (4.0.4) lib/action_controller/metal.rb:231:in `block in action'
  actionpack (4.0.4) lib/action_dispatch/routing/route_set.rb:80:in `call'
  actionpack (4.0.4) lib/action_dispatch/routing/route_set.rb:80:in `dispatch'
  actionpack (4.0.4) lib/action_dispatch/routing/route_set.rb:48:in `call'
  actionpack (4.0.4) lib/action_dispatch/journey/router.rb:71:in `block in call'
  actionpack (4.0.4) lib/action_dispatch/journey/router.rb:59:in `each'
  actionpack (4.0.4) lib/action_dispatch/journey/router.rb:59:in `call'
  actionpack (4.0.4) lib/action_dispatch/routing/route_set.rb:674:in `call'
  bullet (4.8.0) lib/bullet/rack.rb:10:in `call'
  request_store (1.0.5) lib/request_store/middleware.rb:9:in `call'
  rack_session_access (0.1.1) lib/rack_session_access/middleware.rb:33:in `call'
  rack (1.5.2) lib/rack/etag.rb:23:in `call'
  rack (1.5.2) lib/rack/conditionalget.rb:25:in `call'
  rack (1.5.2) lib/rack/head.rb:11:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/params_parser.rb:27:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/flash.rb:241:in `call'
  rack (1.5.2) lib/rack/session/abstract/id.rb:225:in `context'
  rack (1.5.2) lib/rack/session/abstract/id.rb:220:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/cookies.rb:486:in `call'
  activerecord (4.0.4) lib/active_record/query_cache.rb:36:in `call'
  activerecord (4.0.4) lib/active_record/connection_adapters/abstract/connection_pool.rb:626:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
  activesupport (4.0.4) lib/active_support/callbacks.rb:373:in `_run__307158635388222282__call__callbacks'
  activesupport (4.0.4) lib/active_support/callbacks.rb:80:in `run_callbacks'
  actionpack (4.0.4) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/remote_ip.rb:76:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
  railties (4.0.4) lib/rails/rack/logger.rb:38:in `call_app'
  railties (4.0.4) lib/rails/rack/logger.rb:20:in `block in call'
  activesupport (4.0.4) lib/active_support/tagged_logging.rb:68:in `block in tagged'
  activesupport (4.0.4) lib/active_support/tagged_logging.rb:26:in `tagged'
  activesupport (4.0.4) lib/active_support/tagged_logging.rb:68:in `tagged'
  railties (4.0.4) lib/rails/rack/logger.rb:20:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/request_id.rb:21:in `call'
  rack (1.5.2) lib/rack/methodoverride.rb:21:in `call'
  rack (1.5.2) lib/rack/runtime.rb:17:in `call'
  activesupport (4.0.4) lib/active_support/cache/strategy/local_cache.rb:83:in `call'
  actionpack (4.0.4) lib/action_dispatch/middleware/static.rb:64:in `call'
  rack (1.5.2) lib/rack/sendfile.rb:112:in `call'
  railties (4.0.4) lib/rails/engine.rb:511:in `call'
  railties (4.0.4) lib/rails/application.rb:97:in `call'
  rack (1.5.2) lib/rack/builder.rb:138:in `call'
  rack (1.5.2) lib/rack/urlmap.rb:65:in `block in call'
  rack (1.5.2) lib/rack/urlmap.rb:50:in `each'
  rack (1.5.2) lib/rack/urlmap.rb:50:in `call'
  capybara (2.2.1) lib/capybara/server.rb:19:in `call'
  rack (1.5.2) lib/rack/handler/webrick.rb:60:in `service'
  /Users/jriley/.rvm/rubies/ruby-2.0.0-p451/lib/ruby/2.0.0/webrick/httpserver.rb:138:in `service'
  /Users/jriley/.rvm/rubies/ruby-2.0.0-p451/lib/ruby/2.0.0/webrick/httpserver.rb:94:in `run'
  /Users/jriley/.rvm/rubies/ruby-2.0.0-p451/lib/ruby/2.0.0/webrick/server.rb:295:in `block in start_thread'

How can I make this work

Hello,

I have this menu :

• members

--- members new

--- members change

• financial

---- contributie invoices

---- bank
---- cash

Is there a way I can give rights on menu items
Second question : Is there a way I can work with a screen where I can give permissions

Roelof

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Bundler now generates gems with a default 'MIT' license. There is even a License Finder
to help companies ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

If you need help choosing a license, github has created a license picker tool

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for gemspecs not specifying a license as a public service :)
So far it's going pretty well.
I've written a blog post about it

Integration with RailsAdmin

Hi,

Any pointers on how this could be integrated with rails_admin would be much appreciated.

Regards,
Gorav

Verifying if a user can create an instance with certain criteria

I'm trying to create a power that will ensure this user has permission to create items for a particular company.

I have something like this:

power :items do
  Item.where(company_id: @user.company_id)
end

but current_power.item!(new_valid_item) raises Powerless even though the new_valid_item has the proper company_id. It's true that the set of existing items doesn't contain this new item because it's not persisted yet, but I still need to validate it. What is the proper way of performing this check?

Permission File - non-privileged container

Hello,

after updating consul to 1.3.0 I cannot start my app in my non privileged container anymore.

Problem is the permission on active_record.rb, errors.rb, guard.rb and dynamic_access.rb. These files has no read permission for others.

Version 1.2.0

/usr/local/bundle/gems/consul-1.2.0/lib/consul/:
total 48K
drwxr-xr-x 4 root root 4.0K Feb 28 10:09 .
drwxr-xr-x 3 root root 4.0K Feb 28 10:09 ..
-rw-rw-r-- 1 root root  421 Feb 28 10:09 active_record.rb
-rw-rw-r-- 1 root root  308 Feb 28 10:09 errors.rb
-rw-rw-r-- 1 root root 2.9K Feb 28 10:09 guard.rb

/usr/local/bundle/gems/consul-1.2.0/lib/consul/power:
total 12K
drwxr-xr-x 2 root root 4.0K Feb 28 10:09 .
drwxr-xr-x 4 root root 4.0K Feb 28 10:09 ..
-rw-rw-r-- 1 root root 3.1K Feb 28 10:09 dynamic_access.rb

Version 1.3.0

/usr/local/bundle/gems/consul-1.3.0/lib/consul/:
total 52K
drwxr-xr-x 4 root root 4.0K Feb 28 10:21 .
drwxr-xr-x 3 root root 4.0K Feb 28 10:21 ..
-rw-rw---- 1 root root  421 Feb 28 10:21 active_record.rb
-rw-rw---- 1 root root  345 Feb 28 10:21 errors.rb
-rw-rw---- 1 root root 2.9K Feb 28 10:21 guard.rb

/usr/local/bundle/gems/consul-1.3.0/lib/consul/power:
total 12K
drwxr-xr-x 2 root root 4.0K Feb 28 10:21 .
drwxr-xr-x 4 root root 4.0K Feb 28 10:21 ..
-rw-rw---- 1 root root 3.1K Feb 28 10:21 dynamic_access.rb

Did this change happen on purpose?

The dynamically generated query method for powers that return empty arrays returns true

When creating a power that return an ActiveRecord::Relation, I have encountered some unexpected behavior.

power :updatable_users do
  if @user.admin?
    User.all
  else
    User.none
  end
end
.
.
.
current_user = User.create(admin: false)
current_user.admin?                           # returns false
current_power = Power.new(current_user)
current_power.updatable_users                 # return []
current_power.updatable_users.class           # return User::ActiveRecord_Relation < ActiveRecord::Relation
current_power.updatable_users.any?            # returns false
current_power.updatable_users.blank?          # returns false
current_power.updatable_users?                # returns **true**

This is due to this line in the code as !!current_power.updatable_users returns true.

consul/lib/consul/power.rb

Line 21 in 90fdb78

result.respond_to?(:load_target, true) || !!result

I would expect that the current_power.updatable_users? would return the same value as current_power.updatable_users.blank?

    private def default_include_power?(power_name, *context)
      result = send(power_name, *context)
      return true if result.nil?
      return !result.empty? if result.respond_to?(:empty?)

      !!result
    end

Installing with RubyGems 2.5.2

I get the following error when installing Consul 0.12.2 with heroku's install of Rubygems (2.5.2). I have temporarily downgraded consul to 0.12.1 to avoid this.

remote:        Gem::Package::PathError: installing into parent path
remote:        /tmp/build_a6d1f29758d44ec21e9968cc99438621/vendor/bundle/ruby/2.3.0/shared/app_root/app
remote:        of
remote:        /tmp/build_a6d1f29758d44ec21e9968cc99438621/vendor/bundle/ruby/2.3.0/gems/consul-0.12.2
remote:        is not allowed
remote:        An error occurred while installing consul (0.12.2), and Bundler cannot continue.
remote:        Make sure that `gem install consul -v '0.12.2'` succeeds before bundling.

It installs fine with more recent versions of rubygems, but unfortunately we don't have control over the version that heroku uses.

It doesn't look like there is much difference between 0.12.1 <-> 0.12.2 - mostly my commits to remove rails 5 deprecation warnings for *_filter methods.

Any idea what the the Gem::Package::PathError is about?

Incorrect artity calculation for optional block arguments

While consul version 1.0.1 fixed the arity of powers taking block arguments, it led to a bug where the arity is calculated incorretly for optional arguments.

An example

Given this power:

power :fruits do |season, temperature = nil|
  if season == :summer
     Fruit.all
  elsif temperature
    ...
  end
end

In consul 1.0, it's arity was -1, now it claims to be 0:

subject.method(:fruits).arity # 0

The effect of this is that I canot call this power with the right number of arguments:

subject.fruits(:summer)
# => *** ArgumentError Exception: wrong number of arguments (given 1, expected 0)

subject.fruits(:summer, 24)
# => *** ArgumentError Exception: wrong number of arguments (given 2, expected 0)

subject.fruits()
# => *** ArgumentError Exception: wrong number of arguments (given 0, expected 1..2)

How to whitelist controllers whithout applying skip_power_check

Hi Guys,

How can i whitelist/skip controllers from power without applying skip_power_check on every controller.

Security vulnerability: Multiple powers in one controller are not always checked correctly

We have identified a security issue in consul. When a controller has multiple power directives, the :only and :except options of the last directive is applied to all directives. This can lead to unauthenticated access to certain controller actions.

Affected versions: <= 1.0.2
Fixed versions: 1.0.3

Affected code looks like this:

class UsersController < ApplicationController
  power :foo
  power :bar, only: :index

  ...
end

In this example both the powers :foo and :bar are only checked for the #index action. Other actions were left unprotected by powers checks.

Controllers with a single power directive are unaffected. Controllers where neither power uses :only or :except options are unaffected.

This vulnerability has been assigned the CVE identifier CVE-2019-16377.

Misleading error message when arguments (for context-powers) are missing

Say we have the following power:

power :client_notes do |client|
  # ...
end

When calling

Power.current.client_note?(note)

without giving the context client (e.g. Power.current.client_note?(client, note)), the error:

wrong number of arguments (0 for 1)

is thrown, although it needs two arguments instead of one.

Assumption

Since the power query methods are dynamically defined, this might be due to a block taking two parameters. This block does not complain when less parameters are given, however, it probably should. Because it currently does not complain, the actual 0 for 1 arguments error occurs later, leading the wrong direction.

Inheriting from power-protected controllers disables power protection for children

It is common practice to have "base controllers" that hold common functionality for parts of an application. Imagine an "admin area" base controller that protects all its child controllers with the same power:

class Admin::BaseController < ApplicationController
  power :admin
end

class Admin::UsersController < Admin::BaseController
  ...
end

Unfortunately, Admin::UsersController has now lost all power protection! It does not actually check a power, and it does not even raise Consul::UncheckedPower.

The culprit is probably this method, which caches consul guards at the class instance:

consul/lib/consul/controller.rb

Lines 70 to 72 in 41652d1

	def consul_guards
	@consul_guards ||= []
	end

Inheriting classes won't have any Consul guards.

Also, the power check has been removed by this line in #power:

consul/lib/consul/controller.rb

Line 78 in 41652d1

skip_power_check guard.filter_options

Suggested fix: Cache Consul guards properly as class_attribute.

Consul using MongoID (wo Active Record)

Is there a chance to get Consul running on top of MongoID (and MongoDB) ?

Any hint is appreciated

Txs Andi

Do not depend on "rails" gem, depend on parts of Rails that Consul uses

Description

Consul specifies a dependency on rails gem -

consul/consul.gemspec

Line 20 in 41652d1

s.add_dependency('rails')

rails is just an "umbrella gem" that depends on all the components of Ruby on Rails framework - https://github.com/rails/rails/blob/86ca5b254109e64edeb6e142e656b8a8c247cac8/rails.gemspec - ActiveSupport, ActionPack, ActiveRecord, ...

I want to avoid installing actioncable gem in my Rails application. When Consul specifies rails gem as a dependency then actioncable becomes my transitive dependency automatically and there is no way to avoid installing it.

Proposal

Depend only on these parts of Rails that Consul actually uses, for example:

gem.add_dependency "railities"
gem.add_dependency "actionview"

I'm happy to make a PR if you accept the change.

Bang methods should return the scope when successful, not just true

Hey there,

I'm really liking Consul so far, however, there's an aspect of the auto-generated bang methods that I find rather frustrating.

I often-times want, in an index action,. to check if the user has access the resource being indexed; if they do, I want to populate the relevant variable with the list of resource instances they have access to but if they don't I want to raise Consul::Powerless so I can handle it in a rescue_from handler. Normally, I'd expect it to work like this:

@resources = current_power.resources!

...but what I actually need is more like:

@resources = current_power.resources if current_power.resources!

I can't really use

@resources = current_power.resources

alone, either, because if they don't have access to that resource at all (that is, the method returns nil rather than simply an empty set), then I'll get a NoMethodError in the view when I try to iterate over @resources.

I can probably write up a pull request for this, but I thought I'd ask for your opinion on the matter first; there might be a logic to the current behavior that I don't understand, and I didn't want to code up a pull request for something that turns out to be a bad idea.

Limiting assignable attributes

Certain users can write to certain attributes on our model. Could you point me in the right direction with how to do with with consul?

For example:

An Admin can flag a post or edit it. PUT post: { flagged: "because why not?", body: "Removed bad words" }.
The Author of a post, can edit the post's body PUT post: { body: "new body" }.

I don't want to break those out into separate endpoints, as they are both just updating an attribute of the post.

pundit supports this

any advice?

Invalid query syntax for PostgreSQL

The select query generated for Power uses backticks '`'. The syntax is failing with when used with PostgreSQL.

Cannot run the testsuite

Executing "rake" to run the specs gives a LoadError as the spec_helper is missing...

Willing to understand

Hello

I need to improve my knowledge of your gem because I am confident that this is the way to do things but I am still unclear on how to do some simple short of things.

For example:

I have a model User, with common user information. The authorization rule is:

• An administrator can index, show, update, create and destroy any User record.
• An user can index and update (maybe destroy) his/her own record.

I think it is a simple rule, but I am dont know how to match this with the controller.

I implement the power this way:

class Power
  include Consul::Power

  def initialize(user)
    @user = user
  end

  power :users do |entity = nil|
    return User if @user.admin?   
    return User.where(:id => @user.id)
  end

  power :updatable_users do |entity = nil|
    return User if @user.admin?
    return User.where(:id => @user.id)    
  end

  power :creatable_users do |entity = nil|
    return User if @user.admin?
  end

  power :destroyable_users do |entity = nil|
    return User if @user.admin?
  end
end

Then, in the controller, I have the following:

class UsersController < Admin::ApplicationController
  require_power_check
  power :crud => :users

  before_filter :load_record, :only => [:show,:edit,:update,:destroy]
  ... 
  # For example... show:
  def show
    respond_to do |format|
      format.html
    end
  end
  ... 
  def load_record
    if (params[:action] == "show")
      scope = current_power.users
    end    
    if (params[:action]== "edit" || params[:action]== "update" )
      scope = current_power.updatable_users
    end
    if (params[:action]== "destroy" )
      scope = current_power.destroyable_users
    end
    @user = scope.find(params[:id])
  end

  current_power do
    Power.new(current_user)
  end   

end

I don't like the load_record function. I mean: the correct power scope should detected automatically... but this is not the main problem. The problem is that, even if you are not an administrator and don't query your record, the power scope never returns nil.

Maybe the problem can be solved changing the power definition this way:

class Power
  include Consul::Power

  def initialize(user)
    @user = user
  end

  power :users do |entity = nil|
    return User if @user.admin?   
    return User.where(:id => @user.id)
  end

  power :user_show? do |user, entity = nil|
    return @user.admin? or user.id == @user.id
  end

  power :updatable_users do |entity = nil|
    return User if @user.admin?
    return User.where(:id => @user.id)    
  end

  power :updatable_users? do |user, entity = nil|
    return @user.admin? or user.id == @user.id
  end

  power :creatable_users do |entity = nil|
    return User if @user.admin?
  end

  power :destroyable_users do |entity = nil|
    return User if @user.admin?
  end
end

But then I have to set the UsersController so it checks the correct power of its action using a loaded record. Not sure how to do this.

I believe this is a common pattern and I am sure you have a convenient example to implement this.

Can you help me? Thanks a lot!!

Roberto

require_power_check raises exception regardless...

Hi, first of all thanks for this gem, I like the idea of scope-based authorisation. I am having a problem with require_power_check though, in that it always raises an exception regardless of whether an action checks against a power. I always get the

Consul::UncheckedPower:
       This controller does not check against a power

exception. I checked the source and I saw that at the line https://github.com/makandra/consul/blob/master/lib/consul/controller.rb#L102 it's just raising the exception without verifying if a check against the current power has been done.

What am I missing here? Thanks in advance!

Scopes should use exists? rather than checking for inclusion in an id list, by default

For powers that return ActiveRecord::Relations, default_include_object should use exists?(object) rather than plucking the ids from the scope and checking to see if the provided object's id is in the list. Plucking ids doesn't perform all that badly, but, exists? will still always perform better. What's more, it will work in weird edge cases where the primary_key column is not called id (and there is no id column, or the id column is non-unique for some reason), because exists? will call to_key on its argument, rather than just using id.

On that note, even if it turns out that using exists? isn't a good idea, you might consider switching to collecting primary keys, rather than explicitly grabbing the id attribute.

Consul should not crash when calling singular scope powers with `nil`

power :images defines an #image? method that is called like this: power.image?(some_image). When some_image is blank, the call fails with Undefined method 'id' for nil:NilClass. This is caused by object.id in line 35 here:

consul/lib/consul/power.rb

Lines 30 to 36 in 41652d1

	elsif Util.scope?(power_value)
	if Util.scope_selects_all_records?(power_value)
	true
	else
	power_ids_name = self.class.power_ids_name(power_name)
	send(power_ids_name, *context).include?(object.id)
	end

I suggest returning an early false after line 30 when object is nil, because nil can never be a valid value for a scope.

I'll be happy to make a PR if you agree.

current_user is nil

Hello. I'm working on an application that will have some complex authorization and am exploring options. I'm running into issues at the controller level. When I define

module API                                                                                                                                                                                               
  class APIController < ActionController::API                                                                                                                                                          
    include Consul::Controller                                                                                                                                                                       

    current_power do                                                                                                                                                                                 
      Power.new(current_user)                                                                                                                                                                      
    end

    def current_user                                                                                                                                                                                 
      unless @current_user                                                                                                                                                                         
        authenticate do |foo|
          @current_user = Authenticate(foo)
        end
      end                                                                                                                                                                                                                                                                                                                                                                                                    
      @current_user
    end
  end
end

This doesn't seem to resolve current_user within the current_power block. Looks like the documentation has an expectation that you are authenticating with devise, but that is not our case. Any tips on how to get around this? I think consul looks promising for our requirements and would like to get a POC to take to the team