wishfoundry / Authorize

Authentication and Authorization framework rolled into one

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Resource has no effect on rules

stevemo opened this issue · comments

if i declare

Auth::allow('read','user');

Auth::can('read','user'); // return true as expected but this also return true. it should return false since the resource do not match Auth::can('read','post'); // return true
commented

sounds like you have multiple rules colliding

Just try again...

App::before(function($request)
{
Auth::allow('read', 'user');
Auth::can('read', 'user'); //return true
Auth::can('read', 'post'); //return true
});

I'm experiencing the same issue. I've set up an Edit alias, like this:

Auth::addAlias('Edit', [
  'create',
  'store',
  'show',
  'edit',
  'update',
  'logout'
]);

Then, when declaring a rule like this:

Route::filter('role', function() {
  switch(Auth::user()->roles[0]->name){
    case 'Editor':
      Auth::allow('Edit', 'Page');
      break;
  }
}

All resources allow the actions declared in the Edit alias. In fact, the following behaves precisely the same way:

Auth::allow('Edit', null);

Then when using the can method, it treats all resources the same, evaluating to true according to the actions in the Edit alias. So, for example, all the following evaluate to true given the above code:

Auth::can('create', 'Page'); // this is behaving as I expect
Auth::can('create', 'User'); // this is not, it should evaluate to false
Auth::can('create', '');     // again, this is evaluating as true
Auth::can('create', null);   // umm... still true

So I'm not sure if the problem is in Auth::allow() or Auth::can(), but at some point the resource is being disregarded. It appears Auth::deny() and Auth::cannot() are exhibiting the same behavior, but I haven't tested them at all thoroughly.

The upshot is that it doesn't matter how I declare the second parameter in Auth::allow(), the behavior is identical, permitting the actions declared for all resources.

I'll root around a bit in the source and see if anything jumps out at me, but I think I may switch to Machuga's version.

commented

Seems to be an issue with how undefined rules are handled. This should be resolved in the latest commit(few minutes ago)

Thanks @mossnippets for the detailed explanation, it's helps a lot.

Yep, it's working as I'd expect now. Thanks for taking the time, I'm sure you've got more exciting things to do.