joshuaclayton-sentinel 0.1.0 → 0.1.1

data/README.textile

@@ -8,7 +8,7 @@ Sentinels are objects that track permissions.  They're flexible, handy, and very
 
 For example, here's a ForumSentinel:
 
-<code><pre>
+<pre><code>
 class ForumSentinel < Sentinel::Sentinel
   def creatable?
     current_user_admin?
@@ -40,7 +40,7 @@ class ForumSentinel < Sentinel::Sentinel
     current_user? && self.current_user.admin?
   end
 end
-</pre></code>
+</code></pre>
 
 So, what's this guy do?  He personally tracks ability to essentially CRUD a forum, based on the current user.
 
@@ -54,7 +54,7 @@ But, there's more.
 
 You may be asking, "What about when I'm looping through a recordset and want to determine permissions on the fly?"  That's a legitimate question, really.  I've got an easy answer for you.  Imagine your view looks something like this:
 
-<code><pre>
+<pre><code>
 <% @forums.each do |forum| %>
   <% sentinel = ForumSentinel.new(:current_user => current_user, :forum => forum) %>
   <% if sentinel.viewable? %>
@@ -64,11 +64,11 @@ You may be asking, "What about when I'm looping through a recordset and want to
     </div>
   <% end %>
 <% end %>
-</pre></code>
+</code></pre>
 
 You get the idea.  This is still pretty nasty though, since we're instantiating a new sentinel for each item in the recordset.  Let's handle this in the controller.
 
-<code><pre>
+<pre><code>
 class ForumsController < ApplicationController
   controls_access_with do
     ForumSentinel.new :current_user => current_user, :forum => @forum
@@ -76,11 +76,11 @@ class ForumsController < ApplicationController
   
   # ...etc
 end
-</pre></code>
+</code></pre>
 
-Here, we setup the sentinel in the controller and make a @sentinel@ view helper to access the instantiated object.  So, if `@forum` is set up in the show action, we'll have access to it.  The index action, not so much.  Not to fear.
+Here, we setup the sentinel in the controller and make a @sentinel@ view helper to access the instantiated object.  So, if @@forum@ is set up in the show action, we'll have access to it.  The index action, not so much.  Not to fear.
 
-<code><pre>
+<pre><code>
 <% @forums.each do |forum| %>
   <% if sentinel[:forum => forum].viewable? %>
     <div id="<%= dom_id(forum) %>">
@@ -89,17 +89,17 @@ Here, we setup the sentinel in the controller and make a @sentinel@ view helper
     </div>
   <% end %>
 <% end %>
-</pre></code>
+</code></pre>
 
-Essentially the same view as before, except we're not instantiating on every line and it keeps the view nice and clean.  Notice we call `[]`, passing in a hash?  Those are _temporary_ (as in, that call only) overrides.  We assign forum to the current forum we're looping through and have the sentinel return permissions scoped to itself with whatever overrides.
+Essentially the same view as before, except we're not instantiating on every line and it keeps the view nice and clean.  Notice we call @[]@, passing in a hash?  Those are _temporary_ (as in, that call only) overrides.  We assign forum to the current forum we're looping through and have the sentinel return permissions scoped to itself with whatever overrides.
 
-So, handling permissions in the views are pretty easy now; hell, testing should be pretty simple too, since stubbing out simple methods like `viewable?`, `editable?`, etc will be cake.
+So, handling permissions in the views are pretty easy now; hell, testing should be pretty simple too, since stubbing out simple methods like @viewable?@, @editable?@, etc will be cake.
 
 "What about the controllers?" you may ask.  Don't worry about the controllers; this is just as easy.
 
 I introduce to you... @grants_access_to@.
 
-<code><pre>
+<pre><code>
 class ForumsController < ApplicationController
   controls_access_with do
     ForumSentinel.new :current_user => current_user, :forum => @forum
@@ -110,13 +110,13 @@ class ForumsController < ApplicationController
   grants_access_to :viewable?, :only => [:show]
   grants_access_to :destroyable?, :only => [:destroy]
 end
-</pre></code>
+</code></pre>
 
 @grants_access_to@ is essentially a @before_filter@ on crack.  It uses the sentinel we've set up and calls methods on it.  So, if the sentinel returns true when :reorderable? is called, it won't deny the request.  Other filters, however, may.
 
 You need not call methods on the sentinel if you don't want to.  Let's say you want to check if a user is logged in and an admin (contrived example, I know).
 
-<code><pre>
+<pre><code>
 class ForumsController < ApplicationController
   controls_access_with do
     ForumSentinel.new :current_user => current_user, :forum => @forum
@@ -130,13 +130,13 @@ class ForumsController < ApplicationController
     s.creatable? && s.forum.private?
   end
 end
-</pre></code>
+</code></pre>
 
 The first @grants_access_to@ evaluates in the scope of the controller.  If the block passed has an arity of 1 (one required block-level variable), it evaluates in the context of the sentinel.
 
 When granting access, you may want to handle different checks differently.  You can essentially how the controller handles how things are denied.  For example, you may want to include a couple basics within @ApplicationController@.
 
-<code><pre>
+<pre><code>
 class ApplicationController < ActionController::Base
   on_denied_with :forbid_access do
     respond_to do |wants|
@@ -157,11 +157,11 @@ class ApplicationController < ActionController::Base
     end
   end
 end
-</pre></code>
+</code></pre>
   
 If these are set up, you can then have your actions deny with whatever you want, like so: 
 
-<code><pre>
+<pre><code>
 class ForumsController < ApplicationController
   controls_access_with do
     ForumSentinel.new :current_user => current_user, :forum => @forum
@@ -172,7 +172,7 @@ class ForumsController < ApplicationController
   grants_access_to :viewable?, :only => [:show], :denies_with => :unauthorized
   grants_access_to :destroyable?, :only => [:destroy], :denies_with => :forbidden
 end
-</pre></code>
+</code></pre>
 
 Testing the sentinels themselves are fairly easy to do; I won't go into detail with that.
 
@@ -180,7 +180,7 @@ Testing the controllers, however, can be a bit tricky.  Luckily, there are a han
 
 Here's a short example of what you may want to test:
 
-<code><pre>
+<pre><code>
 class SentinelControllerTest < ActionController::TestCase
   include ActionView::Helpers::UrlHelper
   include ActionView::Helpers::TagHelper
@@ -207,9 +207,9 @@ class SentinelControllerTest < ActionController::TestCase
     should_grant_access_to "post :create, :forum => {:name => 'My New Forum'}"
   end
 end
-</pre></code>
+</code></pre>
 
-@sentinel_context@ allows you to stub out responses for whatever methods you want on the sentinel.  Assign attributes (`:current_user`, `:forum`, etc) or stub the permission methods themselves (that's what I would recommend, since your sentinel unit tests should check what the permissions return).
+@sentinel_context@ allows you to stub out responses for whatever methods you want on the sentinel.  Assign attributes (@:current_user@, @:forum@, etc) or stub the permission methods themselves (that's what I would recommend, since your sentinel unit tests should check what the permissions return).
 
 @should_not_guard@ ensures that @grants_access_to@ never gets called on that action.  @should_grant_access_to@ and @should_deny_access_to@ are fairly straightforward.  If @grants_access_to@ denies with a certain handler, you'll want to pass that handler name in (otherwise, you'll have failing tests).
 

data/Rakefile

@@ -3,7 +3,7 @@ require 'rake'
 require 'echoe'
 require 'rake/rdoctask'
 
-Echoe.new("sentinel", "0.1.0") do |p|
+Echoe.new("sentinel", "0.1.1") do |p|
   p.description = "Simple authorization for Rails"
   p.url = "http://github.com/joshuaclayton/sentinel"
   p.author = "Joshua Clayton"

data/lib/sentinel/controller.rb

@@ -45,6 +45,7 @@ module Sentinel
       
       def grants_access_to(*args, &block)
         options = args.extract_options!
+        
         block = args.shift if args.first.respond_to?(:call)
         sentinel_method = args.first
         denied_handler = options.delete(:denies_with) || :default

data/sentinel.gemspec

@@ -2,11 +2,11 @@
 
 Gem::Specification.new do |s|
   s.name = %q{sentinel}
-  s.version = "0.1.0"
+  s.version = "0.1.1"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 1.2") if s.respond_to? :required_rubygems_version=
   s.authors = ["Joshua Clayton"]
-  s.date = %q{2009-04-06}
+  s.date = %q{2009-04-08}
   s.description = %q{Simple authorization for Rails}
   s.email = %q{joshua.clayton@gmail.com}
   s.extra_rdoc_files = ["lib/sentinel/controller.rb", "lib/sentinel/sentinel.rb", "lib/sentinel.rb", "README.textile"]

data/shoulda_macros/sentinel.rb

@@ -18,10 +18,27 @@ module Sentinel
     
     def denied_with(denied_name, &block)
       context "denied_with #{denied_name}" do
+        without_before_filters do # this strips out any other preconditions so we can properly test the handler 
+          setup do
+            action = "action_#{Digest::MD5.hexdigest(Time.now.to_s.split(//).sort_by {rand}.join)}"
+            @controller.class.grants_access_to lambda { false }, :only => [action.to_sym], :denies_with => denied_name
+            get action.to_sym
+          end
+        
+          merge_block(&block)
+        end
+      end
+    end
+    
+    def without_before_filters(&block)
+      context "" do
         setup do
-          action = "action_#{Digest::MD5.hexdigest(Time.now.to_s.split(//).sort_by {rand}.join)}"
-          @controller.class.grants_access_to lambda { false }, :only => [action.to_sym], :denies_with => denied_name
-          get action.to_sym
+          @filter_chain = @controller.class.filter_chain
+          @controller.class.write_inheritable_attribute("filter_chain", ActionController::Filters::FilterChain.new)
+        end
+        
+        teardown do
+          @controller.class.write_inheritable_attribute("filter_chain", @filter_chain)
         end
         
         merge_block(&block)
@@ -51,12 +68,20 @@ module Sentinel
     
     def should_not_guard(command)
       context "performing `#{command}`" do
-        should "not use guard with a sentinel" do
+        setup do
           @controller.class.expects(:access_granted).never
           @controller.class.expects(:access_denied).never
+          @controller.class_eval do
+            def rescue_action(e) raise e end; # force the controller to reraise the exception error
+          end
+        end
+        
+        should "not use guard with a sentinel" do
+          eval command
         end
       end
     end
+    
   end
 end
 

data/test/functional/sentinel_controller_test.rb

@@ -9,7 +9,9 @@ class SentinelControllerTest < ActionController::TestCase
   end
   
   sentinel_context do
-    should_not_guard "get :index"
+    without_before_filters do
+      should_not_guard "get :index"
+    end
   end
   
   sentinel_context({:viewable? => true}) do
@@ -30,15 +32,22 @@ class SentinelControllerTest < ActionController::TestCase
     should_deny_access_to "get :show", :with => :sentinel_unauthorized
   end
   
-  denied_with :redirect_to_index do
-    should_redirect_to("forums root") { url_for(:controller => "forums")}
-  end
-  
-  denied_with :sentinel_unauthorized do
-    should_respond_with :forbidden
+  context "A controller-global grants_access_to that denies access" do
+    # this ensures that, even with a failing grants_access_to, we can properly test all denied_with handlers
+    setup do
+      @controller.stubs(:stubbed_method).returns(false)
+    end
     
-    should "render text as response" do
-      assert_equal "This is an even more unique default restricted warning", @response.body
+    denied_with :redirect_to_index do
+      should_redirect_to("forums root") { url_for(:controller => "forums", :action => "secondary_index")}
+    end
+
+    denied_with :sentinel_unauthorized do
+      should_respond_with :forbidden
+
+      should "render text as response" do
+        assert_equal "This is an even more unique default restricted warning", @response.body
+      end
     end
   end
 end

data/test/partial_rails/controllers/forums_controller.rb

@@ -3,13 +3,19 @@ class ForumsController < ApplicationController
     ForumSentinel.new :current_user => current_user, :forum => @forum
   end
   
+  grants_access_to lambda { stubbed_method }, :denies_with => :redirect_to_index
+  
+  grants_access_to :denies_with => :sentinel_unauthorized do
+    stubbed_method_two
+  end
+  
   grants_access_to :reorderable?, :only => [:reorder]
   grants_access_to :creatable?, :only => [:new, :create], :denies_with => :redirect_to_index
   grants_access_to :viewable?, :only => [:show], :denies_with => :sentinel_unauthorized
   grants_access_to :destroyable?, :only => [:destroy]
   
   on_denied_with :redirect_to_index do
-    redirect_to url_for(:controller => "forums")
+    redirect_to url_for(:controller => "forums", :action => "secondary_index")
   end
   
   on_denied_with :sentinel_unauthorized do
@@ -23,6 +29,10 @@ class ForumsController < ApplicationController
     handle_successfully
   end
   
+  def secondary_index
+    handle_successfully
+  end
+  
   def new
     handle_successfully
   end
@@ -48,4 +58,12 @@ class ForumsController < ApplicationController
   def handle_successfully
     render :text => "forums"
   end
+  
+  def stubbed_method
+    true
+  end
+  
+  def stubbed_method_two
+    true
+  end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification 
 name: joshuaclayton-sentinel
 version: !ruby/object:Gem::Version 
-  version: 0.1.0
+  version: 0.1.1
 platform: ruby
 authors: 
 - Joshua Clayton
@@ -9,7 +9,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2009-04-06 00:00:00 -07:00
+date: 2009-04-08 00:00:00 -07:00
 default_executable: 
 dependencies: 
 - !ruby/object:Gem::Dependency