On Fri, May 8, 2009 at 5:33 AM, doug livesey <biot...@gmail.com> wrote:
> Hi -- I'm writing an app that both requires authentication via a logon, and
> also has roles-based permissions (using acl_system2), and was wondering
> where to verify that both are happening.
> I've started out putting them in a special cucumber feature for
> authentication & permissions, but this is becoming a real drag, as I'm
> writing a scenario for each case (anonymous, lacking permissions, permitted)
> by each controller action.
> Can anyone advise me on a better way to organise this?
>
> Would it be possible to write a security feature for each controller, with
> scenarios for each action? Maybe like this:
> Scenario: Different users trying the index
> Given user is not logged in
> When I go to the controller-a index
> Then I should see "Access Denied"
> Given basic user is logged in
> When I go to the controller-a index
> Then I should see "Insufficient Permissions"
> Given super user is logged in
> When I go to the controller-a index
> Then I should see "Welcome, my lord"
>
> Any advice is very appreciated -- as you can probably tell, this is getting
> messy!
I went down the route of using Scenario Outlines for this, and it
still became messy. There are simply too many cases to cover and the
tables you build up become long and redundant. After a while they all
look start to blur together and look alike. I think these kind of
things belong in controller specs where you can be confident resources
are being protected, but you can also extract out nice little macros.
For example, you might end up with:
desribe PeopleController, "GET index" do
should_allow_logged_in_access_to :superuser
end
You could use a convention of the controller description to determine
the method and the action to hit, or you could parametrize your macro:
should_allow_logged_in_access_to :get, :index, :roles => [:superuser]
I'd recommend not specifying the roles that are denied since if you
had one you'd have to do potentially change every controller spec in
your app. Rather I'd have the macro try a non-allowed role to ensure
it didn't work for other roles.
In the Rails Controllers chapter in The RSpec Book there is a section
on extracting out a should_require_login macro which walks through
step by step the same technique I'd use for writing the macro you
want.
> Cheers,
> Doug.
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
@zachdennis (twitter)
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
