authority 1.0.0.pre3 → 1.0.0.pre4

data/README.markdown

@@ -6,23 +6,34 @@ It requires that you already have some kind of user object in your application,
 
 [![Build Status](https://secure.travis-ci.org/nathanl/authority.png)](http://travis-ci.org/nathanl/authority)
 
-## TL;DR
-
-No time for reading! Reading is for chumps! Here's the skinny:
-
-- Install in your Rails project: add to Gemfile, `bundle`, then `rails g authority:install`
-- For each model you have, create a corresponding [authorizer](#authorizers). For example, for `app/models/lolcat.rb`, create `app/authorizers/lolcat_authorizer.rb` with an empty `class LolcatAuthorizer < Authority::Authorizer`.
-  - Add class methods to that authorizer to set rules that can be enforced just by looking at the resource class, like "this user cannot create Lolcats, period."
-  - Add instance methods to that authorizer to set rules that need to look at a resource instance, like "a user can only edit a Lolcat if it belongs to that user and has not been marked as 'classic'".
-- Wire up your user, models and controllers to work with your authorizers:
-  - In your [user class](#users), `include Authority::UserAbilities`.
-  - Put this in your [controllers](#controllers): `authorize_actions_for YourModelNameHere` (the model that controller works with)
-  - Put this in your [models](#models):  `include Authority::Abilities`
-
+## Contents
+
+<ul>
+  <li><a href="#overview">Overview</a></li>
+  <li><a href="#flow_of_authority">The flow of Authority</a></li>
+  <li><a href="#installation">Installation</a></li>
+  <li><a href="#defining_your_abilities">Defining Your Abilities</a></li>
+  <li><a href="#wiring_it_together">Wiring It Together</a>
+  <ul>
+    <li><a href="#users">Users</a></li>
+    <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>
+    </ul></li>
+    <li><a href="#controllers">Controllers</a></li>
+    <li><a href="#views">Views</a></li>
+  </ul></li>
+  <li><a href="#security_violations_and_logging">Security Violations &amp; Logging</a></li>
+  <li><a href="#credits">Credits</a></li>
+  <li><a href="#contributing">Contributing</a></li>
+</ul>
+
+<a name="overview">
 ## Overview
 
-Still here? Reading is fun! You always knew that. Time for a deeper look at things.
-
 The goals of Authority are:
 
 - To allow broad, class-level rules. Examples: 
@@ -34,274 +45,211 @@ The goals of Authority are:
 - 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 do all of this **without cluttering** either your controllers or your models. This is done by letting Authorizer classes do most of the work. More on that below.
+- To do all this with minimal effort and mess.
 
+<a name="flow_of_authority">
 ## The flow of Authority
 
-In broad terms, the authorization process flows like this:
+Authority encapsulates all authorization logic in `Authorizer` classes. Want to do something with a model? Ask its authorizer.
 
-- 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 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.
 
+<a name="installation">
 ## Installation
 
-First, check in whatever changes you've made to your app already. You want to see what we're doing to your app, don't you?
-
-Now, add this line to your application's Gemfile:
-
-    gem 'authority'
+Starting from a clean commit status, add `authority` to your Gemfile, `bundle`, then `rails g authority:install`.
 
-And then execute:
+<a name="defining_your_abilities">
+## Defining Your Abilities
 
-    $ 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:
 
-Or install it yourself as:
-
-    $ gem install authority
-
-Then run the generator:
-
-    $ rails g authority:install
+    config.abilities =  {
+      :create => 'creatable',
+      :read   => 'readable',
+      :update => 'updatable',
+      :delete => 'deletable'
+    }
 
-Hooray! New files! Go look at them. Look look look.
+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.
 
-## Usage
+<a name="wiring_it_together">
+## Wiring It Together
 
 <a name="users">
 ### Users
-
-Your user model (whatever you call it) should `include Authority::UserAbilities`. This defines methods like `can_update?(resource)`. These methods do nothing but pass the question on to the resource itself. For example, `resource.updatable_by?(user)`.
-
-The list of methods that get defined comes from `config.abilities`.
+In whatever class represents a logged-in user in your application, `include Authority::UserAbilities`.
 
 <a name="models">
 ### Models
-
-In your models, `include Authority::Abilities`. This sets up both class-level and instance-level methods like `creatable_by?(user)`, etc. 
-
-The list of methods that get defined comes from `config.abilities`.
-
-You **could** define those methods yourself on the model, but to keep things organized, we want to put all our authorization logic in authorizer classes. Therefore, these methods, too, are pass-through, which delegate to corresponding methods on the model's authorizer. For example, the `Rabbit` model's `editable_by?(user)` would delegate to `RabbitAuthorizer.editable_by?(user)`.
-
-Which leads us to...
+ 
+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.
 
 <a name="authorizers">
 ### Authorizers
 
-Authorizers should be added under `app/authorizers`, one for each of your models. So if you have a `LaserCannon` model, you should have, at minimum:
+Add your authorizers under `app/authorizers`, subclassing `Authority::Authorizer` or your own authorizer class. (See `rails g authority::authorizers --help`.)
 
-    # app/authorizers/laser_cannon_authorizer.rb
-    class LaserCannonAuthorizer < Authority::Authorizer
-      # Nothing defined - just use the default strategy
-    end
+These are where your actual authorization logic goes. Here's how it works:
 
-These are where your actual authorization logic goes. Here's how you do it:
-
-- 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).
 - 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).
 
-So, suppose you've got the empty `LaserCannonAuthorizer` above and haven't supplied a default strategy. Then you ask the authorizer "is `@laser_cannon_x.deletable_by?(@user_y)`?" It will ask itself:
-
-- "Do I have a `deletable_by?` method, to tell me whether this particular laser cannon can be deleted by this user? ... No."
-- "OK, do I have a `self.deletable_by?` method, to tell me whether **any** laser cannon can be deleted by this user? ... No."
-- "OK, did the user define a default strategy for deciding whether any resource can be deleted by a user? ... No."
-- "Well, I do have a **default** default strategy, which always returns false. So the answer is 'false' - the user can't delete this laser cannon."
-
-As you can see, **you can specify different logic for every method on every model, or [supply a single default strategy](#default_strategies) that covers them all, or anything in between**.
-
-And because the **default** default strategy returns false, we start by assuming that **everything is forbidden**. This whitelisting approach will keep you from accidentally allowing things you didn't intend. 
+For example:
 
-#### An Authorizer Tutorial
+    # app/authorizers/schedule_authorizer.rb
+    class ScheduleAuthorizer < Authority::Authorizer
 
-Let's work our way up from the simplest possible authorizer to see how you can customize your rules.
+      # Class method: can this user at least sometimes create a Schedule?
+      def self.creatable_by?(user)
+        user.manager?
+      end
 
-If your authorizer looks like this:
+      # Instance method: can this user delete this particular schedule?
+      def deletable_by?(user)
+        resource.in_future? && user.manager? && resource.department == user.department
+      end
 
-    # app/authorizers/laser_cannon_authorizer.rb
-    class LaserCannonAuthorizer < Authority::Authorizer
     end
 
-... you will find that everything is forbidden:
+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.
 
-    current_user.can_create?(LaserCannon)    # false; you haven't defined a class-level `can_create?`, so the 
-                                             # `default_strategy` is used. It returns false.
-    current_user.can_create?(@laser_cannon)  # false; instance-level permissions check class-level ones by default,
-                                             # so this is the same as the previous example.
+#### Custom Authorizers
 
-If you update your authorizer as follows:
-
-    # app/authorizers/laser_cannon_authorizer.rb
-    class LaserCannonAuthorizer < Authority::Authorizer
-
-      # Class-level permissions
-      #
-      def self.creatable_by?(user)
-        true # blanket true means that **any** user can create a laser cannon
-      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)` - you can insert a custom class into the inheritance chain.
 
-      def self.deletable_by?(user)
-        false # blanket false means that **no** user can delete a laser cannon
-      end
+    # lib/my_app/authorizer.rb
+    module MyApp
+      class Authorizer < Authority::Authorizer
+      
+        def self.has_permission(user, permission_name)
+          # look that up somewhere
+        end
 
-      # Instance-level permissions
-      #
-      def updatable_by?(user)
-        resource.color == 'blue' && user.first_name == 'Larry' && Date.today.friday?
       end
-
+    end
+  
+    #app/authorizers/badger_authorizer.rb
+    class BadgerAuthorizer < MyApp::Authorizer
+      # contents
     end
 
-... you can now do the following:
+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`.
 
-    current_user.can_create?(LaserCannon)    # true, per class method above
-    current_user.can_create?(@laser_cannon)  # true; inherited instance method calls class method
-    current_user.can_delete?(@laser_cannon)  # false
-    current_user.can_update?(@laser_cannon)  # Only Larry, only blue laser cannons, and only on 
-                                             # Fridays (weapons maintenance day)
 <a name="default_strategies">
 #### Default Strategies
 
-To take a different approach, if you wanted to answer all these questions in a uniform way - perhaps by looking up permissions in a database table - you could just supply a default strategy that does that.
+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?
+      # Does the user have any of the roles which give this permission?
+      (roles_which_grant(able, authorizer) & user.roles).any?
     }
 
-That's it! All your authorizer classes could be left empty.
-
-<a name="controllers">
-### Controllers
-
-#### Basic Usage
-
-In your controllers, add this method call:
+<a name="testing_authorizers">
+#### Testing Authorizers
 
-    authorize_actions_for ModelName
+One nice thing about putting your authorization logic in authorizers is the ease of testing. Here's a brief example.
 
-That sets up a `before_filter` that **calls your class-level methods before each action**. For instance, before running the `update` action, it will check whether the current user (determined using the configurable `user_method`) `can_update?(ModelName)` at a class level. A return value of false means "this user can never update models of this class."
+    # An authorizer shared by several admin-only models
+    describe AdminAuthorizer do
 
-By the way, any options you pass in will be used on the `before_filter` that gets created, so you can do things like this:
-
-    authorize_actions_for InvisibleSwordsman, :only => :show
-
-#### Usage within a controller action
+      before :each do 
+        @user  = Factory.build(:user)
+        @admin = Factory.build(:admin)
+      end
 
-If you need to check some attributes of a model instance to decide if an action is permissible, you can use the **singular** `authorize_action_for(@resource_instance)`. This method will determine which controller action it was called from, look at the controller action map, determine which method should be checked on the model, and check it.
+      describe "class" do
+        it "should let admins update in bulk" do
+          AdminAuthorizer.should be_bulk_updatable_by(@admin)
+        end
 
-The default controller action map is as follows:
+        it "should not let users update in bulk" do
+          AdminAuthorizer.should_not be_bulk_updatable_by(@user)
+        end
+      end
 
-    {
-      :index   => 'read',   # index action requires that the user can_read?(resource)
-      :show    => 'read',   # etc
-      :new     => 'create',
-      :create  => 'create',
-      :edit    => 'update',
-      :update  => 'update',
-      :destroy => 'delete'
-    }
+      describe "instances" do
 
-So, for example, if you did this:
+        before :each do
+          # A mock model that uses AdminAuthorizer
+          @admin_resource_instance = mock_admin_resource
+        end
 
-    class MessageController < ApplicationController
-    ...
+        it "should not allow users to delete" do
+          @admin_resource_instance.authorizer.should_not be_deletable_by(@user)
+        end
 
-      def edit
-        @message = Message.find(params[:id])
-        authorize_action_for(@message)
       end
-      ...
 
     end
 
-... Authority would determine that it was called from within `edit`, that the `edit` controller action requires permission to `update`, and check whether the current user `can_update?(@message)`.
+<a name="controllers">
+### Controllers
 
-Each controller gets its own copy of the controller action map. If you want to edit a **single** controller's action map, you can either pass a hash into `authorize_actions_for`, which will get merged into the existing actions hash...
+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:
 
-    class BadgerController < ApplicationController
-      authorize_actions_for Badger, :actions => {:neuter => 'update'}
-      ...
-    end
+- `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.
 
-...or you can use a separate method call:
+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 BadgerController < ApplicationController
-      authorize_actions_for Badger
+    class LlamaController < ApplicationController
 
-      authority_action :neuter => 'update'
+      # 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'
 
       ...
-    end
 
-Finally, if you want to update this hash for **all** your controllers, you can do that with `config.controller_action_map` in the initializer.
+      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
 
-## Views
+    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)`
+    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** (cue cheesy, dramatic music).
+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.
 
-## Security Violations
+<a name="security_violations_and_logging">
+## Security Violations & Logging
 
 Anytime a user attempts an unauthorized action, Authority does two things:
 
 - Renders your `public/403.html`
 - Logs the violation to whatever logger you configured.
 
-If you want to set 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.
-
-## Configuration
-
-Configuration should be done from `config/initializers/authority.rb`, which will be generated for you by `rails g authority:install`. That file includes copious documentation. Copious, do you hear me?!
-
-Ahem. Note that the configuration block in that file **must** run in your application. Authority metaprograms its methods on boot, but waits until your configuration block has run to do so. If you want the default settings, you don't have to put anything in your configure block, but you must at least run `Authority.configure`.
-
-Some of the things you can configure which haven't already been mentioned are...
-
-### Abilities
+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 
 
-If you want to be able to say `user.can_eat?` and have Authority ask the model and authorizer if the resource is `edible_by?` the user, edit your `config.abilities` to include `{:eat => 'edible'}`.
+    "Kenneth Lay is not allowed to delete this resource: 'accounting_tricks.doc'"
 
-### Logging
-
-Authority will log a message any time a user tries to access a resource for which they are not authorized. By default, this is logged to standard error, but you can supply whatever logger you want, as long as it responds to `warn`. Some possible settings are:
-
-    config.logger = Rails.logger
-    config.logger = Logger.new('logs/authority.log') # From Ruby standard library
-
-## Custom authorizer inheritence
-
-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`.
-
-## Integration Notes
-
-- If you want to have nice log messages for security violations, you should ensure that your user object has a `to_s` method; this will control how it shows up in log messages saying things like "**Kenneth Lay** is not allowed to delete this resource:..."
+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.
 
+<a name="credits">
 ## Credits, AKA 'Shout-Outs'
 
 - [adamhunter](https://github.com/adamhunter) for pairing with me on this gem. The only thing faster than his typing is his brain.
@@ -309,12 +257,10 @@ If you decide to place your custom class in `lib` as shown above (as opposed to
 - [jnunemaker](https://github.com/jnunemaker) for later creating [Canable](http://github.com/jnunemaker/canable), another inspiration for Authority.
 - [TMA](http://www.tma1.com) for employing me and letting me open source some of our code.
 
+<a name="contributing">
 ## Contributing
 
-What should you contribute? Some ideas:
-
-- Documentation improvements will always be welcome (though of course, whether something is an improvement will be up to me to decide).
-- Look in the separate TODO file or grep the project for 'TODO' for other ideas.
+What should you contribute? Try the TODO file for ideas, or grep the project for 'TODO' comments.
 
 How can you contribute?
 

data/TODO.markdown

@@ -6,12 +6,9 @@
 
 ## Chores
 
-- Add separate generator to make an empty authorizer for each file in `app/models` (prompt for each one)
 - Test generators
+- Configurable proc for logging method
 
 ## Documentation
 
-- Make README more concise, or at least more navigable.
-- How to bypass creating an authorizer for each model - by setting authorizer name directly and having them share.
-- For instance-level checks, ensuring that you don't call `update` first; use `attributes=` before calling `authorize_action_on`.
 - 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?

data/lib/authority.rb

@@ -26,13 +26,12 @@ module Authority
   # @param [Symbol] action
   # @param [Model] resource instance
   # @param [User] user instance
-  # @raise [SecurityTransgression] if user is not allowed to perform action on resource
+  # @raise [SecurityViolation] if user is not allowed to perform action on resource
   # @return [Model] resource instance
   def self.enforce(action, resource, user)
     action_authorized = user.send("can_#{action}?", resource)
     unless action_authorized
-      message = "#{user} is not authorized to #{action} this resource: #{resource.inspect}"
-      raise SecurityTransgression.new(message)
+      raise SecurityViolation.new(user, action, resource)
     end
     resource
   end
@@ -57,7 +56,17 @@ module Authority
     require 'authority/user_abilities'
   end
 
-  class SecurityTransgression < StandardError ; end
+  class SecurityViolation < StandardError
+    def initialize(user, action, resource)
+      @user = user
+      @action = action
+      @resource = resource
+    end
+
+    def message
+      "#{@user} is not authorized to #{@action} this resource: #{@resource}"
+    end
+  end
 
 end
 

data/lib/authority/abilities.rb

@@ -11,6 +11,7 @@ module Authority
     extend ActiveSupport::Concern
 
     # Let the Foo model know that its authorizer is called 'FooAuthorizer'
+    # (but let the user change that)
     included do
       class_attribute :authorizer_name
       self.authorizer_name = "#{name}Authorizer"

data/lib/authority/controller.rb

@@ -6,7 +6,7 @@ module Authority
     extend ActiveSupport::Concern
 
     included do
-      rescue_from Authority::SecurityTransgression, :with => :authority_forbidden
+      rescue_from Authority::SecurityViolation, :with => :authority_forbidden
       class_attribute :authority_resource
     end
 

data/lib/authority/version.rb

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

data/lib/generators/authority/authorizers_generator.rb

@@ -0,0 +1,47 @@
+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

data/lib/generators/templates/authority_initializer.rb

@@ -42,6 +42,9 @@ Authority.configure do |config|
   # For a given controller method, what verb must a user be able to do?
   # For example, a user can access 'show' if they 'can_read' the resource.
   #
+  # These can be modified on a per-controller basis; see README. This option
+  # applies to all controllers.
+  #
   # Defaults are as follows:
   #
   # config.controller_action_map = {
@@ -77,9 +80,9 @@ Authority.configure do |config|
   # config.logger = Logger.new(STDERR)
   #
   # Some possible settings:
-  # config.logger = Rails.logger
-  # config.logger = Logger.new('logs/authority.log')
-  # config.logger = Logger.new('/dev/null')
+  # config.logger = Rails.logger                     # Log with all your app's other messages
+  # config.logger = Logger.new('logs/authority.log') # Use this file
+  # config.logger = Logger.new('/dev/null')          # Don't log at all (on a Unix system)
 
 end
 

data/spec/authority/controller_spec.rb

@@ -8,7 +8,7 @@ describe Authority::Controller do
 
   describe "when including" do
     it "should specify rescuing security transgressions" do
-      SampleController.should_receive(:rescue_from).with(Authority::SecurityTransgression, :with => :authority_forbidden)
+      SampleController.should_receive(:rescue_from).with(Authority::SecurityViolation, :with => :authority_forbidden)
       SampleController.send(:include, Authority::Controller)
     end
   end
@@ -68,8 +68,8 @@ describe Authority::Controller do
         @controller.send(:run_authorization_check)
       end
 
-      it "should raise a SecurityTransgression if authorization fails" do
-        expect { @controller.send(:run_authorization_check) }.to raise_error(Authority::SecurityTransgression)
+      it "should raise a SecurityViolation if authorization fails" do
+        expect { @controller.send(:run_authorization_check) }.to raise_error(Authority::SecurityViolation)
       end
 
       it "should raise a MissingAction if there is no corresponding action for the controller" do

data/spec/authority_spec.rb

@@ -44,12 +44,12 @@ describe Authority do
       @user = User.new
     end
 
-    it "should raise a SecurityTransgression if the action is unauthorized" do
-      expect { Authority.enforce(:update, AbilityModel, @user) }.to raise_error(Authority::SecurityTransgression)
+    it "should raise a SecurityViolation if the action is unauthorized" do
+      expect { Authority.enforce(:update, AbilityModel, @user) }.to raise_error(Authority::SecurityViolation)
     end
 
-    it "should not raise a SecurityTransgression if the action is authorized" do
-      expect { Authority.enforce(:read, AbilityModel, @user) }.not_to raise_error(Authority::SecurityTransgression)
+    it "should not raise a SecurityViolation if the action is authorized" do
+      expect { Authority.enforce(:read, AbilityModel, @user) }.not_to raise_error(Authority::SecurityViolation)
     end
 
   end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: authority
 version: !ruby/object:Gem::Version
-  version: 1.0.0.pre3
+  version: 1.0.0.pre4
   prerelease: 6
 platform: ruby
 authors:
@@ -10,11 +10,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2012-03-20 00:00:00.000000000 Z
+date: 2012-03-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails
-  requirement: &2164558540 !ruby/object:Gem::Requirement
+  requirement: &2152325920 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -22,10 +22,10 @@ dependencies:
         version: 3.0.0
   type: :runtime
   prerelease: false
-  version_requirements: *2164558540
+  version_requirements: *2152325920
 - !ruby/object:Gem::Dependency
   name: bundler
-  requirement: &2164557960 !ruby/object:Gem::Requirement
+  requirement: &2152325380 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -33,7 +33,7 @@ dependencies:
         version: 1.0.0
   type: :development
   prerelease: false
-  version_requirements: *2164557960
+  version_requirements: *2152325380
 description: Gem for managing authorization on model actions in Rails.
 email:
 - nathanmlong@gmail.com
@@ -61,6 +61,7 @@ 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