> This is great. I have a question about AND-ing if_attribute or
> passing additional conditions. Is it possible?

following your example, the easiest way is to combine those attributes:
if_attribute :owner => is {user}, :color => “blue”

> Or pass named_scopes as conditions
> # if_attribute :named_scope?(user) => is{true}
>
> Or pass arguments to attributes
> # if_attribute :find_this(user)

No, currently if_attribute is limited to attributes and associations. Could you give me an extended, real-world example to convince me that this is actually necessary?

> Also, could you say a bit more or give an example of the
> :context option in use?

E.g. in
has_permission_on :employees, :to => :read
the context is :employees. In controllers, the context is usually inferred from the controller name (e.g. EmployeesController). If a different context should be employed for authorization checks, you can pass that with the :context option.

The documentation at
http://www.tzi.org/~sbartsch/declarative_authorization/0.1/
could be of additional help.

Steffen

This is great. I have a question about AND-ing if_attribute or passing additional conditions. Is it possible?

These are all pseudo-code, but hopefully get the gist across.

Something like
if_attribute :owner => is{user} and if_attribute :color => is{”blue”}

Or pass named_scopes as conditions
# if_attribute :named_scope?(user) => is{true}

Or pass arguments to attributes
# if_attribute :find_this(user)

Also, could you say a bit more or give an example of the :context option in use?

Thanks,
Sarah

actually I implemented ignore_access_control for the test environment where I frequently need to setup objects and don’t like the access control hassle there. But you are right, there are other use cases for such a feature. I’m not sure how to separate that properly from the day-to-day business of the application, though. I’d prefer to don’t have such an option there.

As for without_access_control, I have such a method in my test helper. I plan to integrate it as test infrastructure into the plugin in the future. Looks like this in my helper:


def without_access_control
Authorization.ignore_access_control(true)
yield
ensure
Authorization.ignore_access_control(false)
end

def with_user (user)
prev_user = Authorization.current_user
Authorization.current_user = user
yield
ensure
Authorization.current_user = prev_user
end


Steffen

using_access_control is really cool, but for me, it can get in the way at times. (For example, when working with objects in the console, or setting up that all-important first admin user.) To help with this problem, I made a couple of changes to authorization.rb.

Modified one existing method:


# Modified this method to return @@ignore_access_control without also checking RAILS_ENV. This
# was done to allow us to switch access control on and off as needed.
def self.ignore_access_control (state = nil) # :nodoc:
@@ignore_access_control = state unless state.nil?
@@ignore_access_control
end


And added one new method:


# Executes a given block, bypassing all access control. Useful for legitimate cases where access
# control "gets in the way" (e.g., bootstrapping that first admin user, console work).
def self.without_access_control( &block )
state = self.ignore_access_control
raise AuthorizationError unless self.ignore_access_control( true )
yield
self.ignore_access_control( state )
nil
end


It’s probably not a very good solution (I’m definitely NOT the expert here), but it gets the job done. Any better ideas?

> I’m attempting to use the advanced permission rule to allow
> the current_user to :manage their own message, but only :read
> everyone else’s.
>
> In my case I am using a Person model instead of User.
>
> However, the current_user always gets the manage permission
> has_permission_on :messages, :to => :read
> has_permission_on :messages do
> to :manage
> if_attribute :person_id => is {user.id}
> end

has_permission_on :messages, :to => :read
has_permission_on :messages do
to :manage
if_attribute :person => is {user}
end

is perfectly correct. I have similar code working here. Could you verify that

message.person != person_object_of_the_request

for the request? Also, does it help to remove the second has_permission_on statement? In the rails console, you could also try:

engine = Authorization::Engine.instance
engine.permit!(:manage,
:context => :messages,
:user => person_object_of_the_request,
:object => message_object)

to drill down on the problem.

Steffen

:context options just directly set the context for the authorization evaluation, see the rdoc documentation for more information on that.

I suppose with “title” you are referring to the Role model proposed in the README. Here, title is just the name of the role as specified in the authorization rules.

Steffen

on your question concerning the error on PeopleController, I just checked a fix into github to prevent the unnecessary second pluralization. That should fix it.

Steffen

the role would be “admin” for an overall admin and “project_admin” for one limited to assigned projects. For restricting access to the assigned projects, use the if_attribute context restriction. E.g.

role :project_admin
has_permissions_on :project, :to => :manage do
if_attribute :admin_users => contains { user }
end
end

Provided, that your Project model has a project#admin_users collection (has_many :admin_users, :through …).

Does this help?
Steffen

In my case I am using a Person model instead of User.

However, the current_user always gets the manage permission
has_permission_on :messages, :to => :read
has_permission_on :messages do
to :manage
# user refers to the current_user when evaluating
if_attribute :person_id => is {user.id}
end

I’ve also tried:
if_attribute :person => is {user}
if_attribute :person.id => contains {user.id}
if attribute :person => is {person}

but none of these actually deny the manage permission. What am I doing wrong?

Thanks!

has_permission_on :people, :to => :manage

I’m getting a permission denied…

:context => :peoples