authority 1.0.0.pre4 → 1.0.0

data/CHANGELOG.markdown

@@ -2,6 +2,15 @@
 
 This is mainly to document major new features and backwards-incompatible changes.
 
+## v1.0.0
+
+- Added `config.security_violation_handler` so users can specify which controller method to use when rescuing `SecurityViolation`s
+- Removed generator to make blank authorizers. On further consideration, one authorizer per model is counterproductive for most use cases, and I'd rather not encourage misuse.
+
+## v1.0.0.pre4
+
+Added generator to make blank authorizers. See `rails g authority:authorizers --help`.
+
 ## v1.0.0.pre3
 
 - Rename controller methods (again):

data/README.markdown

@@ -1,8 +1,10 @@
 # Authority
 
-Authority gives you a clean and easy way to say, in your Rails app, **who** is allowed to do **what** with your models. Unauthorized actions get a warning and an entry in a log file.
+Authority helps you authorize actions in your Rails app. It's **ORM-neutral** and has very little fancy syntax; just group your models under one or more Authorizer classes and write plain Ruby methods on them.
 
-It requires that you already have some kind of user object in your application, accessible from all controllers (like `current_user`).
+Authority will work fine with a standalone app or a single sign-on system. You can check roles in a database or permissions in a YAML file. It doesn't care! What it **does** do is give you an easy way to organize your logic, define a default strategy, and handle unauthorized actions.
+
+It requires that you already have some kind of user object in your application, accessible from all controllers and views via a method like `current_user` (configurable).
 
 [![Build Status](https://secure.travis-ci.org/nathanl/authority.png)](http://travis-ci.org/nathanl/authority)
 
@@ -19,9 +21,9 @@ It requires that you already have some kind of user object in your application,
     <li><a href="#models">Models</a></li>
     <li><a href="#authorizers">Authorizers</a>
     <ul>
-      <li><a href="#custom_authorizers">Custom Authorizers</a></li>
       <li><a href="#default_strategies">Default strategies</a></li>
       <li><a href="#testing_authorizers">Testing Authorizers</a></li>
+      <li><a href="#custom_authorizers">Custom Authorizers</a></li>
     </ul></li>
     <li><a href="#controllers">Controllers</a></li>
     <li><a href="#views">Views</a></li>
@@ -36,29 +38,59 @@ It requires that you already have some kind of user object in your application,
 
 The goals of Authority are:
 
-- To allow broad, class-level rules. Examples: 
+- To allow broad, **class-level** rules. Examples: 
   - "Basic users cannot delete any Widget."
   - "Only admin users can create Offices."
-- To allow fine-grained, instance-level rules. Examples: 
+- To allow fine-grained, **instance-level** rules. Examples: 
   - "Management users can only edit schedules with date ranges in the future."
   - "Users can't create playlists more than 20 songs long unless they've paid."
 - To provide a clear syntax for permissions-based views. Example:
   - `link_to 'Edit Widget', edit_widget_path(@widget) if current_user.can_update?(@widget)`
-- To gracefully handle any access violations: display a "you can't do that" screen and log the violation.
+- To gracefully handle any access violations: by default, it displays a "you can't do that" screen and logs the violation.
 - To do all this with minimal effort and mess.
 
 <a name="flow_of_authority">
 ## The flow of Authority
 
-Authority encapsulates all authorization logic in `Authorizer` classes. Want to do something with a model? Ask its authorizer.
+Authority encapsulates all authorization logic in `Authorizer` classes. Want to do something with a model? **Ask its authorizer**.
+
+You can group models under authorizers in any way you wish. For example:
+
+
+        +-------------+              +--------------+                               +-------------+
+        |Simplest case|              |Logical groups|                               |Most granular|
+        +-------------+              +--------------+                               +-------------+
+
+        default_strategy              default_strategy                              default_strategy
+               +                             +                                             +
+               |                    +--------+-------+                 +-------------------+-------------------+
+               +                    +                +                 +                   +                   +
+       EverythingAuthorizer  BasicAuthorizer   AdminAuthorizer  CommentAuthorizer  ArticleAuthorizer  EditionAuthorizer
+               +                    +                +                 +                   +                   +
+       +-------+-------+            +-+       +------+                 |                   |                   |
+       +       +       +              +       +      +                 +                   +                   +
+    Comment Article Edition        Comment Article Edition          Comment             Article             Edition
+
 
 The process generally flows like this:
 
-- In a controller or view, a user object is asked whether it can do some action to a resource class or instance, like `current_user.can_create?(Widget)` or `current_user.can_update?(@widget)`.
-- The user just asks the model the same question: `resource.creatable_by?(self)`.
-- The model passes that question to its Authorizer, which actually contains the logic to answer the question.
-- The Authorizer returns an answer back up the call chain to the original caller.
-- If the answer is "no" and the original caller was a controller, this is treated as a `SecurityViolation`. If it was a view, maybe you just don't show a link.
+                   current_user.can_create?(Moose)                   # You ask this question, and the user
+                               +                                     # automatically asks the model...
+                               |
+                               v
+                   Moose.creatable_by?(current_user)                 # The model automatically asks
+                               +                                     # its authorizer...
+                               |
+                               v
+               MooseAuthorizer.creatable_by?(current_user)           # *You define this method.*
+                               +                                     # If it's missing, the default
+                               |                                     # strategy is used...
+                               v
+    config.default_strategy.call(:creatable, MooseAuthorizer, user)  # *You define this strategy.*
+
+If the answer is `false` and the original caller was a controller, this is treated as a `SecurityViolation`. If it was a view, maybe you just don't show a link.
+
+(Diagrams made with [AsciiFlow](http://asciiflow.com))
 
 <a name="installation">
 ## Installation
@@ -70,12 +102,14 @@ Starting from a clean commit status, add `authority` to your Gemfile, `bundle`,
 
 Edit `config/initializers/authority.rb`. That file documents all your options, but one of particular interest is `config.abilities`, which defines the verbs and corresponding adjectives in your app. The defaults are:
 
-    config.abilities =  {
-      :create => 'creatable',
-      :read   => 'readable',
-      :update => 'updatable',
-      :delete => 'deletable'
-    }
+```ruby
+config.abilities =  {
+  :create => 'creatable',
+  :read   => 'readable',
+  :update => 'updatable',
+  :delete => 'deletable'
+}
+```
 
 This option determines what methods are added to your users, models and authorizers. If you need to ask `user.can_deactivate?(Satellite)` and `@satellite.deactivatable_by?(user)`, add those to the hash.
 
@@ -84,170 +118,215 @@ This option determines what methods are added to your users, models and authoriz
 
 <a name="users">
 ### Users
-In whatever class represents a logged-in user in your application, `include Authority::UserAbilities`.
+
+```ruby
+# Whatever class represents a logged-in user in your app
+class User 
+  # Adds `can_create?(resource)`, etc
+  include Authority::Abilities
+...
+end
+```
 
 <a name="models">
 ### Models
- 
-In every model, `include Authority::Abilities`. Give every model an [Authorizer](#authorizers). By default, the `Llama` model will look for a `LlamaAuthorizer`. To specify a different one, call `authorizer_name UngulateAuthorizer`; this way, the `UngulateAuthorizer` could also protect the `Zebra` and `Antelope` models, or the `AdminAuthorizer` could protect business-critical models.
+
+```ruby
+class Article
+  # Adds `creatable_by?(user)`, etc
+  include Authority::Abilities
+
+  # Without this, 'ArticleAuthorizer' is assumed
+  self.authorizer_name = 'AdminAuthorizer'
+  ...
+end
+```
 
 <a name="authorizers">
 ### Authorizers
 
-Add your authorizers under `app/authorizers`, subclassing `Authority::Authorizer` or your own authorizer class. (See `rails g authority::authorizers --help`.)
+Add your authorizers under `app/authorizers`, subclassing `Authority::Authorizer`.
 
 These are where your actual authorization logic goes. Here's how it works:
 
 - Instance methods answer questions about model instances, like "can this user update this **particular** widget?" (Within an instance method, you can get the model instance with `resource`).
   - Any instance method you don't define (for example, if you didn't make a `def deletable_by?(user)`) will fall back to the corresponding class method. In other words, if you haven't said whether a user can update **this particular** widget, we'll decide by checking whether they can update **any** widget.
 - Class methods answer questions about model classes, like "is it **ever** permissible for this user to update a Widget?"
-  - Any class method you don't define (for example, if you didn't make a `def self.updatable_by?(user)`) will fall back to your [configurable default strategy](#default_strategies).
+  - Any class method you don't define (for example, if you didn't make a `def self.updatable_by?(user)`) will fall back to your configurable [default strategy](#default_strategies).
 
 For example:
 
-    # app/authorizers/schedule_authorizer.rb
-    class ScheduleAuthorizer < Authority::Authorizer
-
-      # Class method: can this user at least sometimes create a Schedule?
-      def self.creatable_by?(user)
-        user.manager?
-      end
-
-      # Instance method: can this user delete this particular schedule?
-      def deletable_by?(user)
-        resource.in_future? && user.manager? && resource.department == user.department
-      end
-
-    end
+```ruby
+# app/authorizers/schedule_authorizer.rb
+class ScheduleAuthorizer < Authority::Authorizer
+  # Class method: can this user at least sometimes create a Schedule?
+  def self.creatable_by?(user)
+    user.manager?
+  end
+
+  # Instance method: can this user delete this particular schedule?
+  def deletable_by?(user)
+    resource.in_future? && user.manager? && resource.department == user.department
+  end
+end
+```
 
 As you can see, you can specify different logic for every method on every model, if necessary. On the other extreme, you could simply supply a [default strategy](#default_strategies) that covers all your use cases.
 
-#### Custom Authorizers
-
-If you want to customize your authorizers even further - for example, maybe you want them all to have a method like `has_permission?(user, permission_name)` - you can insert a custom class into the inheritance chain.
-
-    # lib/my_app/authorizer.rb
-    module MyApp
-      class Authorizer < Authority::Authorizer
-      
-        def self.has_permission(user, permission_name)
-          # look that up somewhere
-        end
-
-      end
-    end
-  
-    #app/authorizers/badger_authorizer.rb
-    class BadgerAuthorizer < MyApp::Authorizer
-      # contents
-    end
-
-If you decide to place your custom class in `lib` as shown above (as opposed to putting it in `app`), you should require it at the bottom of `config/initializers/authority.rb`.
-
 <a name="default_strategies">
 #### Default Strategies
 
-Any class method you don't define on an authorizer will use your default strategy. The **default** default strategy simply returns false, meaning that everything is forbidden. This whitelisting approach will keep you from accidentally allowing things you didn't intend. 
+Any class method you don't define on an authorizer will use your default strategy. The **default** default strategy simply returns `false`, meaning that everything is forbidden. This whitelisting approach will keep you from accidentally allowing things you didn't intend. 
 
 You can configure a different default strategy. For example, you might want one that looks up permissions in your database:
 
-    # In config/initializers/authority.rb
-    config.default_strategy = Proc.new { |able, authorizer, user|
-      # Does the user have any of the roles which give this permission?
-      (roles_which_grant(able, authorizer) & user.roles).any?
-    }
+```ruby
+# In config/initializers/authority.rb
+config.default_strategy = Proc.new do |able, authorizer, user|
+  # Does the user have any of the roles which give this permission?
+  (roles_which_grant(able, authorizer) & user.roles).any?
+end
+```
+
+If your system is uniform enough, **this strategy alone might handle all the logic you need**.
 
 <a name="testing_authorizers">
 #### Testing Authorizers
 
 One nice thing about putting your authorization logic in authorizers is the ease of testing. Here's a brief example.
 
-    # An authorizer shared by several admin-only models
-    describe AdminAuthorizer do
+```ruby
+# An authorizer shared by several admin-only models
+describe AdminAuthorizer do
 
-      before :each do 
-        @user  = Factory.build(:user)
-        @admin = Factory.build(:admin)
-      end
+  before :each do 
+    @user  = FactoryGirl.build(:user)
+    @admin = FactoryGirl.build(:admin)
+  end
 
-      describe "class" do
-        it "should let admins update in bulk" do
-          AdminAuthorizer.should be_bulk_updatable_by(@admin)
-        end
+  describe "class" do
+    it "should let admins update in bulk" do
+      AdminAuthorizer.should be_bulk_updatable_by(@admin)
+    end
+
+    it "should not let users update in bulk" do
+      AdminAuthorizer.should_not be_bulk_updatable_by(@user)
+    end
+  end
+
+  describe "instances" do
+
+    before :each do
+      # A mock model that uses AdminAuthorizer
+      @admin_resource_instance = mock_admin_resource
+    end
 
-        it "should not let users update in bulk" do
-          AdminAuthorizer.should_not be_bulk_updatable_by(@user)
-        end
-      end
+    it "should not allow users to delete" do
+      @admin_resource_instance.authorizer.should_not be_deletable_by(@user)
+    end
 
-      describe "instances" do
+  end
 
-        before :each do
-          # A mock model that uses AdminAuthorizer
-          @admin_resource_instance = mock_admin_resource
-        end
+end
+```
 
-        it "should not allow users to delete" do
-          @admin_resource_instance.authorizer.should_not be_deletable_by(@user)
-        end
+<a name="custom_authorizers">
+#### Custom Authorizers
 
-      end
+If you want to customize your authorizers even further - for example, maybe you want them all to have a method like `has_permission?(user, permission_name)` - just use normal Ruby inheritance. For example, add your own parent class, like this:
 
+```ruby
+# lib/my_app/authorizer.rb
+module MyApp
+  class Authorizer < Authority::Authorizer
+  
+    def self.has_permission(user, permission_name)
+      # look that up somewhere
     end
 
+  end
+end
+
+#app/authorizers/badger_authorizer.rb
+class BadgerAuthorizer < MyApp::Authorizer
+  # contents
+end
+```
+
+If you decide to place your custom class in `lib` as shown above (as opposed to putting it in `app`), you should require it at the bottom of `config/initializers/authority.rb`.
+
 <a name="controllers">
 ### Controllers
 
 Anytime a controller finds a user attempting something they're not authorized to do, a [Security Violation](#security_violations_and_logging) will result. Controllers get two ways to check authorization:
 
-- `authorize_actions_for Transaction` protects multiple controller actions with a `before_filter`, which performs a class-level check. If the current user is never allowed to delete a `Transaction`, they'll never even get to the controller's `destroy` method.
-- `authorize_action_for @transaction` can be called inside a single controller action, and performs an instance-level check. If called inside `update`, it will check whether the current user is allowed to update this particular `@transaction` instance.
+- `authorize_actions_for Transaction` protects multiple controller actions with a `before_filter`, which performs a **class-level** check. If the current user is never allowed to delete a `Transaction`, they'll never even get to the controller's `destroy` method.
+- `authorize_action_for @transaction` can be called inside a single controller action, and performs an **instance-level** check. If called inside `update`, it will check whether the current user is allowed to update this particular `@transaction` instance.
 
 The relationship between controller actions and abilities - like checking `readable_by?` on the `index` action - is configurable both globally, using `config.controller_action_map`, and per controller, as below.
 
-    class LlamaController < ApplicationController
+```ruby
+class LlamaController < ApplicationController
 
-      # Check class-level authorizations before all actions except :create
-      # Before this controller's 'neuter' action, ask whether current_user.can_update?(Llama)
-      authorize_actions_for Llama, :actions => {:neuter => :update}, :except => :create
-      
-      # Before this controller's 'breed' action, ask whether current_user.can_create?(Llama)
-      authority_action :breed => 'new'
+  # Check class-level authorizations before all actions except :create
+  # Before this controller's 'neuter' action, ask whether current_user.can_update?(Llama)
+  authorize_actions_for Llama, :actions => {:neuter => :update}, :except => :create
+  
+  # Before this controller's 'breed' action, ask whether current_user.can_create?(Llama)
+  authority_action :breed => 'new'
 
-      ...
+  ...
 
-      def edit
-        @llama = Llama.find(params[:id])
-        @llama.attributes = params[:llama]  # Don't save the attributes before authorizing
-        authorize_action_for(@llama)        # failure == SecurityViolation
-        if @llama.save?
-        # etc
-      end
+  def edit
+    @llama = Llama.find(params[:id])
+    @llama.attributes = params[:llama]  # Don't save the attributes before authorizing
+    authorize_action_for(@llama)        # failure == SecurityViolation
+    if @llama.save?
+    # etc
+  end
 
-    end
+end
+```
 
 <a name="views">
 ### Views
 
 Assuming your user object is available in your views, you can do all kinds of conditional rendering. For example:
 
-    link_to 'Edit Widget', edit_widget_path(@widget) if current_user.can_update?(@widget)
+```ruby
+link_to 'Edit Widget', edit_widget_path(@widget) if current_user.can_update?(@widget)
+```
 
 If the user isn't allowed to edit widgets, they won't see the link. If they're nosy and try to hit the URL directly, they'll get a [Security Violation](#security_violations_and_logging) from the controller.
 
 <a name="security_violations_and_logging">
 ## Security Violations & Logging
 
-Anytime a user attempts an unauthorized action, Authority does two things:
+Anytime a user attempts an unauthorized action, Authority calls whatever controller method is specified by your `security_violation_handler` option, handing it the exception. The default handler is `authority_forbidden`, which Authority adds to your `ApplicationController`. It does the following:
 
-- Renders your `public/403.html`
+- Renders `public/403.html`
 - Logs the violation to whatever logger you configured.
 
-If you want to have nice log messages for security violations, you should ensure that your user object and models have `to_s` methods; this will control how they show up in log messages saying things like 
+You can specify a different handler like so:
+
+```ruby
+# config/initializers/authority.rb
+...
+config.security_violation_handler = :fire_ze_missiles
+...
+
+# app/controllers/application_controller.rb
+class ApplicationController < ActionController::Base
 
-    "Kenneth Lay is not allowed to delete this resource: 'accounting_tricks.doc'"
+  def fire_ze_missiles(exception)
+    # Log? Set a flash message? Dispatch minions to 
+    # fill their mailbox with goose droppings? It's up to you.
+  end
+...
+end
+```
 
-If you feel like setting up a `cron` job to watch the log file, look up the user's name and address, and dispatch minions to fill their mailbox with goose droppings, that's really up to you. I got nothing to do with it, man.
+If you want different error handling per controller, define `fire_ze_missiles` on each of them.
 
 <a name="credits">
 ## Credits, AKA 'Shout-Outs'
@@ -264,11 +343,12 @@ What should you contribute? Try the TODO file for ideas, or grep the project for
 
 How can you contribute?
 
-1. Fork this project
-2. Create your feature branch (`git checkout -b my-new-feature`)
-3. `bundle install` to get all dependencies
-4. `rspec spec` to run all tests.
-5. Update/add tests for your changes and code until they pass.
-6. Commit your changes (`git commit -am 'Added some feature'`)
-7. Push to the branch (`git push origin my-new-feature`)
-8. Create a new Pull Request
+1. Let's talk! Before you do a bunch of work, open an issue so we can be sure we agree.
+2. Fork this project
+3. Create your feature branch (`git checkout -b my-new-feature`)
+4. `bundle install` to get all dependencies
+5. `rspec spec` to run all tests.
+6. Update/add tests for your changes and code until they pass.
+7. Commit your changes (`git commit -am 'Added some feature'`)
+8. Push to the branch (`git push origin my-new-feature`)
+9. Create a new Pull Request

data/TODO.markdown

@@ -1,14 +1,13 @@
 # TODO
 
-## Design
-
-- Carefully think through names of all public methods & see if they could be clearer or more intuitive
-
 ## Chores
 
-- Test generators
-- Configurable proc for logging method
+- Add tests for the generators
 
 ## Documentation
 
 - Example of checking clean/dirty attributes in instance-level checks. For example, if I'm only allowed to update blue laser cannons, can I make them red? Maybe I need to check whether the old value was blue?
+
+## Features
+
+- It would be nice to have an `authorized_link_to` method, which determines from the given path and the user's permissions whether to show the link. Not sure yet how hard this would be.

data/authority.gemspec

@@ -4,8 +4,8 @@ require File.expand_path('../lib/authority/version', __FILE__)
 Gem::Specification.new do |gem|
   gem.authors       = ["Nathan Long", "Adam Hunter"]
   gem.email         = ["nathanmlong@gmail.com", "adamhunter@me.com"]
-  gem.description   = %q{Gem for managing authorization on model actions in Rails.}
-  gem.summary       = %q{Authority gives you a clean and easy way to say, in your Rails app, **who** is allowed to do **what** with your models, with minimal clutter.}
+  gem.summary       = %q{Authority helps you authorize actions in your Rails app using plain Ruby methods on Authorizer classes.}
+  gem.description   = %q{Authority helps you authorize actions in your Rails app. It's ORM-neutral and has very little fancy syntax; just group your models under one or more Authorizer classes and write plain Ruby methods on them.}
   gem.homepage      = "https://github.com/nathanl/authority"
 
   gem.add_dependency "rails", ">= 3.0.0"

data/lib/authority/configuration.rb

@@ -3,12 +3,13 @@ module Authority
 
     # Has default settings, overrideable in the initializer.
 
-    attr_accessor :default_strategy, :abilities, :controller_action_map, :user_method, :logger
+    attr_accessor :default_strategy, :abilities, :controller_action_map, :user_method, :security_violation_handler, :logger
 
     def initialize
-      @default_strategy = Proc.new { |able, authorizer, user|
+      @default_strategy = Proc.new do |able, authorizer, user|
         false
-      }
+      end
+      
 
       @abilities = {
         :create => 'creatable',
@@ -29,6 +30,8 @@ module Authority
 
       @user_method = :current_user
 
+      @security_violation_handler = :authority_forbidden
+
       @logger = Logger.new(STDERR)
     end
 

data/lib/authority/controller.rb

@@ -6,10 +6,18 @@ module Authority
     extend ActiveSupport::Concern
 
     included do
-      rescue_from Authority::SecurityViolation, :with => :authority_forbidden
+      rescue_from(Authority::SecurityViolation, :with => Authority::Controller.security_violation_callback)
       class_attribute :authority_resource
     end
 
+    def self.security_violation_callback
+      Proc.new do |exception|
+        # Through the magic of ActiveSupport's Proc#bind, `ActionController::Base#rescue_from`
+        # can call this proc and make `self` the actual controller instance
+        self.send(Authority.configuration.security_violation_handler, exception)
+      end
+    end
+
     module ClassMethods
 
       # Sets up before_filter to ensure user is allowed to perform a given controller action
@@ -37,6 +45,7 @@ module Authority
       def authority_action_map
         @authority_action_map ||= Authority.configuration.controller_action_map.dup
       end
+
     end
 
     protected

data/lib/authority/version.rb

@@ -1,3 +1,3 @@
 module Authority
-  VERSION = "1.0.0.pre4"
+  VERSION = "1.0.0"
 end

data/lib/generators/authority/install_generator.rb

@@ -5,9 +5,32 @@ module Authority
     class InstallGenerator < Rails::Generators::Base
 
       source_root File.expand_path("../../templates", __FILE__)
-
       desc "Creates an Authority initializer for your application." 
 
+      def do_all
+        copy_initializer
+        copy_forbidden
+        create_authorizers_directory
+        message = <<-RUBY
+
+        Install complete! See the README on Github for instructions on getting your
+        app running with Authority.
+
+        One note: each model needs to know the name of its its authorizer class. 
+        You can specify that in the model like `authorizer_name FooAuthorizer`.
+        If you don't, the `Article` model (for example) will look for `ArticleAuthorizer`.
+
+        To generate one authorizer like that for each of your models, see
+        `rails g authority:authorizers`. If you also want to specify your own
+        parent class for them, use `rails g authority:authorizers MyClass`.
+
+        RUBY
+        puts message.strip_heredoc
+        
+      end
+
+      private
+
       def copy_initializer
         template "authority_initializer.rb", "config/initializers/authority.rb"
       end

data/lib/generators/templates/authority_initializer.rb

@@ -70,10 +70,18 @@ Authority.configure do |config|
   #   :update => 'updatable',
   #   :delete => 'deletable'
   # }
+
+  # SECURITY_VIOLATION_HANDLER
+  # If a SecurityViolation is raised, what controller method should be used to rescue it?
+  #
+  # Default is:
+  #
+  # config.security_violation_handler = :authority_forbidden # Defined in controller.rb
   
   # LOGGER
   # If a user tries to perform an unauthorized action, where should we log that fact?
-  # Provide a logger object which responds to `.warn(message)`
+  # Provide a logger object which responds to `.warn(message)`, unless your 
+  # security_violation_handler calls a different method.
   #
   # Default is:
   #

data/spec/authority/controller_spec.rb

@@ -3,14 +3,41 @@ require 'support/ability_model'
 require 'support/example_controllers'
 require 'support/mock_rails'
 require 'support/user'
+require 'active_support/core_ext/proc'
 
 describe Authority::Controller do
 
+  describe "the security violation callback" do
+
+    it "should call whatever method on the controller that the configuration specifies" do
+      # Here be dragons!
+      @fake_exception = Exception.new
+      @sample_controller = SampleController.new
+      # If a callback is passed to a controller's `rescue_from` method as the value for 
+      # the `with` option (like `SomeController.rescue_from FooException, :with => some_callback`),
+      # Rails will use ActiveSupport's `Proc#bind` to ensure that when the proc refers to 
+      # `self`, it will be the controller, not the proc itself.
+      # I need this callback's `self` to be the controller for the purposes of
+      # this test, so I'm stealing that behavior.
+      @callback = Authority::Controller.security_violation_callback.bind(@sample_controller)
+
+      Authority.configuration.security_violation_handler = :fire_ze_missiles
+      @sample_controller.should_receive(:fire_ze_missiles).with(@fake_exception)
+      @callback.call(@fake_exception)
+    end
+  end
+
   describe "when including" do
-    it "should specify rescuing security transgressions" do
-      SampleController.should_receive(:rescue_from).with(Authority::SecurityViolation, :with => :authority_forbidden)
+
+    before :each do
+      Authority::Controller.stub(:security_violation_callback).and_return(Proc.new {|exception| })
+    end
+
+    it "should specify rescuing security violations with a standard callback" do
+      SampleController.should_receive(:rescue_from).with(Authority::SecurityViolation, :with => Authority::Controller.security_violation_callback)
       SampleController.send(:include, Authority::Controller)
     end
+
   end
 
   describe "after including" do

metadata

@@ -1,8 +1,8 @@
 --- !ruby/object:Gem::Specification
 name: authority
 version: !ruby/object:Gem::Version
-  version: 1.0.0.pre4
-  prerelease: 6
+  version: 1.0.0
+  prerelease: 
 platform: ruby
 authors:
 - Nathan Long
@@ -10,11 +10,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2012-03-26 00:00:00.000000000 Z
+date: 2012-04-17 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails
-  requirement: &2152325920 !ruby/object:Gem::Requirement
+  requirement: &82923350 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -22,10 +22,10 @@ dependencies:
         version: 3.0.0
   type: :runtime
   prerelease: false
-  version_requirements: *2152325920
+  version_requirements: *82923350
 - !ruby/object:Gem::Dependency
   name: bundler
-  requirement: &2152325380 !ruby/object:Gem::Requirement
+  requirement: &82923030 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -33,8 +33,10 @@ dependencies:
         version: 1.0.0
   type: :development
   prerelease: false
-  version_requirements: *2152325380
-description: Gem for managing authorization on model actions in Rails.
+  version_requirements: *82923030
+description: Authority helps you authorize actions in your Rails app. It's ORM-neutral
+  and has very little fancy syntax; just group your models under one or more Authorizer
+  classes and write plain Ruby methods on them.
 email:
 - nathanmlong@gmail.com
 - adamhunter@me.com
@@ -61,7 +63,6 @@ files:
 - lib/authority/railtie.rb
 - lib/authority/user_abilities.rb
 - lib/authority/version.rb
-- lib/generators/authority/authorizers_generator.rb
 - lib/generators/authority/install_generator.rb
 - lib/generators/templates/403.html
 - lib/generators/templates/authority_initializer.rb
@@ -92,26 +93,14 @@ required_ruby_version: !ruby/object:Gem::Requirement
 required_rubygems_version: !ruby/object:Gem::Requirement
   none: false
   requirements:
-  - - ! '>'
+  - - ! '>='
     - !ruby/object:Gem::Version
-      version: 1.3.1
+      version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 1.8.16
+rubygems_version: 1.8.10
 signing_key: 
 specification_version: 3
-summary: Authority gives you a clean and easy way to say, in your Rails app, **who**
-  is allowed to do **what** with your models, with minimal clutter.
-test_files:
-- spec/authority/abilities_spec.rb
-- spec/authority/authorizer_spec.rb
-- spec/authority/configuration_spec.rb
-- spec/authority/controller_spec.rb
-- spec/authority/user_abilities_spec.rb
-- spec/authority_spec.rb
-- spec/spec_helper.rb
-- spec/support/ability_model.rb
-- spec/support/example_controllers.rb
-- spec/support/mock_rails.rb
-- spec/support/no_authorizer_model.rb
-- spec/support/user.rb
+summary: Authority helps you authorize actions in your Rails app using plain Ruby
+  methods on Authorizer classes.
+test_files: []

data/lib/generators/authority/authorizers_generator.rb

@@ -1,47 +0,0 @@
-require 'rails/generators/base'
-
-module Authority
-  module Generators
-    class AuthorizersGenerator < Rails::Generators::Base
-
-      argument :parentClass, type: :string, default: 'Authority::Authorizer', banner: 'Parent class'
-
-      def make_authorizer_folder
-        # creates empty directory if none; doesn't empty the directory
-        empty_directory authorizer_folder
-      end
-
-      desc "Generates one authorizer per model, with confirmation. Optionally, give name of parent class." 
-      def make_authorizers
-        authorizer_names.each do |authorizer_name|
-          filename = File.join(authorizer_folder, authorizer_name.underscore).concat('.rb')
-          create_file filename do
-            contents = <<-RUBY
-              class #{authorizer_name} < #{parentClass} 
-                # Define class and instance methods
-              end
-            RUBY
-            contents.strip_heredoc
-          end
-        end
-      end
-
-      # Non-public generator methods aren't automatically called
-      private
-
-      def authorizer_folder
-        'app/authorizers'
-      end
-
-      def authorizer_names
-        # TODO: Make Dir.glob recursive(**), in case there are model subdirs,
-        # and create same structure in authorizers
-        models_dir = File.join(Rails.root, 'app', 'models', '*.rb')
-        Dir.glob(models_dir).map do |filepath| 
-          filepath.split(/models./).last.gsub(/\.rb\z/, '').camelcase.concat('Authorizer')
-        end
-      end
-
-    end
-  end
-end