authlogic 2.0.9 → 2.0.11

data/CHANGELOG.rdoc

@@ -1,3 +1,20 @@
+== 2.0.11 release 2009-4-25
+
+* Fix bug when password is turned off and the SingleAccessToken module calls the after_password_set callback.
+* HTTP basic auth can now be toggled on or off. It also checks for the existence of a standard username and password before enabling itself.
+* Added option check_passwords_against_database for Authlogic::ActsAsAuthentic::Password to toggle between checking the password against the database value or the object value. Also added the same functionality to the instance method: valid_password?("password", true), where the second argument tells Authlogic to check the password against the database value. The default for this new feature is true.
+* Add a maintain_sessions configuration option to Authlogic::ActsAsAuthentic::SessionMaintenance as a "clearer" option to disable automatic session maintenance.
+* single_access_allowed_request_types can also be equal to :all instead of just [:all].
+* Refactor params_enabled? so that the single_access_allowed? method in controllers takes precedence.
+* Added testing comments in the README and expanded on the documentation in Authlogic::TestCase
+
+== 2.0.10 release 2009-4-21
+
+* Mock request is now transparent to non existent methods. Since the methods calls really have no functional value when testing authlogic.
+* Allow password confirmation to be disabled.
+* Modified login format validation to allow for the + character since emails addresses allow that as a valid character.
+* Added merge_* configuration methods for acts_as_authentic to make merging options into configuration options that default to hashes. Just a few convenience methods.
+
 == 2.0.9 release 2009-4-9
 
 * Fixed bug where hooks provided by the password module were called when the password module was not being used due to the fact that the password field did not exist.
@@ -13,7 +30,7 @@
 
 == 2.0.6 release 2009-4-9
 
-* Don't use second, use [1] instead so older rails systems don't complain.
+* Don't use second, use [1] instead so older rails versions don't complain.
 * Update email regular expression to be less TLD specific: (?:[A-Z]{2,4}|museum|travel)
 * Update shoulda macro for 2.0
 * validates_length_of_password_confirmation_field_options defaults to validates_confirmation_of_password_field_options

data/Manifest.txt

@@ -82,9 +82,11 @@ test/fixtures/companies.yml
 test/fixtures/employees.yml
 test/fixtures/projects.yml
 test/fixtures/users.yml
+test/libs/affiliate.rb
 test/libs/company.rb
 test/libs/employee.rb
 test/libs/employee_session.rb
+test/libs/ldaper.rb
 test/libs/ordered_hash.rb
 test/libs/project.rb
 test/libs/user.rb

data/README.rdoc

@@ -2,103 +2,111 @@
 
 Authlogic is a clean, simple, and unobtrusive ruby authentication solution.
 
-What inspired me to create Authlogic was the messiness of the current authentication solutions. Put simply, they just didn't feel right, because the logic was not organized properly. As you may know, a common misconception with the MVC design pattern is that the model "M" is only for data access logic, which is wrong. A model is a place for domain logic. This is why the RESTful design pattern and the current authentication solutions don't play nice. Authlogic solves this by placing the session maintenance logic into its own domain (aka "model"). Moving session maintenance into its own domain has its benefits:
+A code example can replace a thousand words...
+
+Authlogic introduces a new type of model. You can have as many as you want, and name them whatever you want, just like your other models. In this example we want to authenticate with the User model, which is inferred by the name:
+
+  class UserSession < Authlogic::Session::Base
+  end
+
+Log in with any of the following. Use it just like your other models:
 
-1. It's easier to update and stay current with the latest security practices. Since authlogic sits in between you and your session it can assist in keeping your security up to date. For example: upgrading your hashing algorithm, helping you transition to a new algorithm, etc. Since all of this logic is in the Authlogic library, staying up to date is as easy as updating the library.
-2. It ties everything together on the domain level. Take a new user registration for example, no reason to manually log the user in, authlogic handles this for you via callbacks. The same applies to a user changing their password. Authlogic handles maintaining the session for you.
-3. Your application can stay clean, focused, and free of redundant authentication code from app to app. Meaning generators are *NOT* necessary. Not any more neccessary than any other control
-4. A byproduct of #3 is that you don't have to test the same code over and over in each of your apps. You don't test the internals of ActiveRecord in each of your apps, so why would you test the internals of Authlogic? It's already been thoroughly tested for you. Focus on your application, and get rid of the noise by testing your application specific code and not generated code that you didn't write.
-5. You get to write your own code, just like you do for any other model. Meaning the code you write is specific to your application, the way you want it, and more importantly you understand it.
-6. You are not restricted to a single session. Think about Apple's me.com, where they need you to authenticate a second time before changing your billing information. Why not just create a second session for this? It works just like your initial session. Then your billing controller can require an "ultra secure" session.
+  UserSession.create(my_user_object)
+  UserSession.create(:login => "bjohnson", :password => "my password")
+  session = UserSession.new(:login => "bjohnson", :password => "my password"); session.save
+  UserSession.create(:openid_identifier => "identifier") # requires the authlogic-oid "add on" gem
 
-Authlogic can do all of this and much more, keep reading to see...
+After a session has been created, you can persist it across requests. Thus keeping the user logged in:
+
+  session = UserSession.find
+
+You can also log out / destroy the session:
+
+  session.destroy
 
 == Helpful links
 
 *	<b>Documentation:</b> http://authlogic.rubyforge.org
-*	<b>Live example with OpenID "add on" & source code:</b> http://authlogicexample.binarylogic.com
-*	<b>Tutorial: Authlogic basic setup:</b> http://www.binarylogic.com/2008/11/3/tutorial-authlogic-basic-setup
+*	<b>Repository:</b> http://github.com/binarylogic/authlogic/tree/master
+*	<b>Live example with OpenID "add on":</b> http://authlogicexample.binarylogic.com
+*	<b>Live example repository with tutorial:</b> http://github.com/binarylogic/authlogic_example/tree/master
 *	<b>Tutorial: Reset passwords with Authlogic the RESTful way:</b> http://www.binarylogic.com/2008/11/16/tutorial-reset-passwords-with-authlogic
-*	<b>Tutorial: Easily migrate from restful_authentication:</b> http://www.binarylogic.com/2008/11/23/tutorial-easily-migrate-from-restful_authentication-to-authlogic
-*	<b>Tutorial: Upgrade passwords easily with Authlogic:</b> http://www.binarylogic.com/2008/11/23/tutorial-upgrade-passwords-easily-with-authlogic
 * <b>Bugs / feature suggestions:</b> http://binarylogic.lighthouseapp.com/projects/18752-authlogic
 * <b>Google group:</b> http://groups.google.com/group/authlogic
 
-<b>Before contacting me, please read:</b>
+<b>Before contacting me directly, please read:</b>
 
-If you find a bug or a problem please post it on lighthouse. If you need help with something, please use google groups. I check both regularly and get emails when anything happens, so that is the best place to get help.
-
-Please do not email me directly with issues regarding Authlogic. This is an inefficient way to get help because it doesn't help people who have the same problem in the future.
+If you find a bug or a problem please post it on lighthouse. If you need help with something, please use google groups. I check both regularly and get emails when anything happens, so that is the best place to get help. This also benefits other people in the future with the same questions / problems. Thank you.
 
 == Authlogic "add ons"
 
 *	<b>Authlogic OpenID addon:</b> http://github.com/binarylogic/authlogic_openid
 *	<b>Authlogic LDAP addon:</b> http://github.com/binarylogic/authlogic_ldap
 
-If you create one of your own, please let me know about it so I can add it to this list.
+If you create one of your own, please let me know about it so I can add it to this list. Or just fork the project, add your link, and send me a pull request.
 
-== Documentation
+== Documentation explanation
 
-You can find anything you want about Authlogic in the documentation, all that you need to do is understand the basic design behind it.
+You can find anything you want about Authlogic in the {documentation}, all that you need to do is understand the basic design behind it.
 
-That being said, Authlogic is split into 2 main parts:
+That being said, there are 2 models involved during authentication. Your Authlogic model and your ActiveRecord model:
 
-  1. Authlogic::Session, which manages sessions.
-  2. Authlogic::ActsAsAuthentic, which adds in functionality to your ActiveRecord model.
+1. <b>Authlogic::Session</b>, your session models that extend Authlogic::Session::Base.
+2. <b>Authlogic::ActsAsAuthentic</b>, which adds in functionality to your ActiveRecord model when you call acts_as_authentic.
 
-Each of the above has its various sub modules that contain common logic. The sub modules are responsible for including everything related to it: configuration, class methods, instance methods, etc.
+Each of the above has its various sub modules that contain common logic. The sub modules are responsible for including *everything* related to it: configuration, class methods, instance methods, etc.
 
-For example, if you want to timeout users after a certain period of inactivity, you would look in Authlogic::Session::Timeout. To help you out, I listed the following "publicly relevant" modules with short descriptions. For the sake of brevity, there are more modules than listed here, the ones not listed are more for internal use, but you can easily read up on them in the documentation.
+For example, if you want to timeout users after a certain period of inactivity, you would look in <b>Authlogic::Session::Timeout</b>. To help you out, I listed the following "publicly relevant" modules with short descriptions. For the sake of brevity, there are more modules than listed here, the ones not listed are more for internal use, but you can easily read up on them in the {documentation}[http://authlogic.rubyforge.org].
 
 === Authlogic::ActsAsAuthentic sub modules
 
-These modules are for the acts_as_authentic method you call in your model. It contains all code for the "model side" of the authentication.
-
-* Authlogic::ActsAsAuthentic::Base - Provides the acts_as_authentic class method and includes all of the submodules.
-* Authlogic::ActsAsAuthentic::Email - Handles everything related to the email field.
-* Authlogic::ActsAsAuthentic::LoggedInStatus - Provides handy named scopes and methods for determining if the user is logged in or out.
-* Authlogic::ActsAsAuthentic::Login - Handles everything related to the login field.
-* Authlogic::ActsAsAuthentic::MagicColumns - Handles everything related to the "magic" fields: login_count, failed_login_count, etc.
-* Authlogic::ActsAsAuthentic::Password - This one is important. It handles encrypting your password, salting it, etc. It also has support for transitioning password algorithms.
-* Authlogic::ActsAsAuthentic::PerishableToken - Handles maintaining the perishable token field, also provides a class level method for finding record using the token.
-* Authlogic::ActsAsAuthentic::PersistenceToken - Handles maintaining the persistence token. This is the token stored in cookies and sessions to persist the users session.
-* Authlogic::ActsAsAuthentic::RestfulAuthentication - Provides configuration options to easily migrate from the restful_authentication plugin.
-* Authlogic::ActsAsAuthentic::SessionMaintenance - Handles automatically logging the user in. EX: a new user registers, automatically log them in.
-* Authlogic::ActsAsAuthentic::SingleAccessToken - Handles maintaining the single access token.
-* Authlogic::ActsAsAuthentic::ValidationsScope - Allows you to scope validations, etc. Just like the :scope option for validates_uniqueness_of
+These modules are for the ActiveRecord side of things, the models that call acts_as_authentic.
+
+* <b>Authlogic::ActsAsAuthentic::Base</b> - Provides the acts_as_authentic class method and includes all of the submodules.
+* <b>Authlogic::ActsAsAuthentic::Email</b> - Handles everything related to the email field.
+* <b>Authlogic::ActsAsAuthentic::LoggedInStatus</b> - Provides handy named scopes and methods for determining if the user is logged in or out.
+* <b>Authlogic::ActsAsAuthentic::Login</b> - Handles everything related to the login field.
+* <b>Authlogic::ActsAsAuthentic::MagicColumns</b> - Handles everything related to the "magic" fields: login_count, failed_login_count, etc.
+* <b>Authlogic::ActsAsAuthentic::Password</b> - This one is important. It handles encrypting your password, salting it, etc. It also has support for transitioning password algorithms.
+* <b>Authlogic::ActsAsAuthentic::PerishableToken</b> - Handles maintaining the perishable token field, also provides a class level method for finding record using the token.
+* <b>Authlogic::ActsAsAuthentic::PersistenceToken</b> - Handles maintaining the persistence token. This is the token stored in cookies and sessions to persist the users session.
+* <b>Authlogic::ActsAsAuthentic::RestfulAuthentication</b> - Provides configuration options to easily migrate from the restful_authentication plugin.
+* <b>Authlogic::ActsAsAuthentic::SessionMaintenance</b> - Handles automatically logging the user in. EX: a new user registers, automatically log them in.
+* <b>Authlogic::ActsAsAuthentic::SingleAccessToken</b> - Handles maintaining the single access token.
+* <b>Authlogic::ActsAsAuthentic::ValidationsScope</b> - Allows you to scope validations, etc. Just like the :scope option for validates_uniqueness_of
 
 === Authlogic::Session sub modules
 
-These modules are for the "session side" of authentication. They create a new domain for session logic, allowing you to create, destroy, and ultimately manage your sessions.
-
-* Authlogic::Session::BruteForceProtection - Disables accounts after a certain number of consecutive failed logins attempted.
-* Authlogic::Session::Callbacks - Your tools to extend, change, or add onto Authlogic. Lets you hook in and do just about anything you want. Start here if you want to write a plugin or add on for Authlogic
-* Authlogic::Session::Cookies - Authentication via cookies.
-* Authlogic::Session::Existence - Creating, saving, and destroying objects.
-* Authlogic::Session::HttpAuth - Authentication via basic HTTP authentication.
-* Authlogic::Session::Id - Allows sessions to be separated by an id, letting you have multiple sessions for a single user.
-* Authlogic::Session::MagicColumns - Maintains "magic" database columns, similar to created_at and updated_at for ActiveRecord.
-* Authlogic::Session::MagicStates - Automatically validates based on the records states: active?, approved?, and confirmed?. If those methods exist for the record.
-* Authlogic::Session::Params - Authentication via params, aka single access token.
-* Authlogic::Session::Password - Authentication via a traditional username and password.
-* Authlogic::Session::Persistence - Persisting sessions / finding sessions.
-* Authlogic::Session::Session - Authentication via the session, the controller session that is.
-* Authlogic::Session::Timeout - Automatically logging out after a certain period of inactivity.
-* Authlogic::Session::UnauthorizedRecord - Handles authentication by passing an ActiveRecord object.
-* Authlogic::Session::Validation - Validation / errors.
+These modules are for the models that extend Authlogic::Session::Base.
+
+* <b>Authlogic::Session::BruteForceProtection</b> - Disables accounts after a certain number of consecutive failed logins attempted.
+* <b>Authlogic::Session::Callbacks</b> - Your tools to extend, change, or add onto Authlogic. Lets you hook in and do just about anything you want. Start here if you want to write a plugin or add on for Authlogic
+* <b>Authlogic::Session::Cookies</b> - Authentication via cookies.
+* <b>Authlogic::Session::Existence</b> - Creating, saving, and destroying objects.
+* <b>Authlogic::Session::HttpAuth</b> - Authentication via basic HTTP authentication.
+* <b>Authlogic::Session::Id</b> - Allows sessions to be separated by an id, letting you have multiple sessions for a single user.
+* <b>Authlogic::Session::MagicColumns</b> - Maintains "magic" database columns, similar to created_at and updated_at for ActiveRecord.
+* <b>Authlogic::Session::MagicStates</b> - Automatically validates based on the records states: active?, approved?, and confirmed?. If those methods exist for the record.
+* <b>Authlogic::Session::Params</b> - Authentication via params, aka single access token.
+* <b>Authlogic::Session::Password</b> - Authentication via a traditional username and password.
+* <b>Authlogic::Session::Persistence</b> - Persisting sessions / finding sessions.
+* <b>Authlogic::Session::Session</b> - Authentication via the session, the controller session that is.
+* <b>Authlogic::Session::Timeout</b> - Automatically logging out after a certain period of inactivity.
+* <b>Authlogic::Session::UnauthorizedRecord</b> - Handles authentication by passing an ActiveRecord object.
+* <b>Authlogic::Session::Validation</b> - Validation / errors.
 
 === Miscellaneous modules
 
-Miscellaneous modules that don't really belong solely to either the session or model aspect.
+Miscellaneous modules that shared across the authentication process and are more "utility" modules and classes.
 
-* Authlogic::AuthenticatesMany - Responsible for allowing you to scope sessions to a parent record. Similar to a has_many and belongs_to relationship. This lets you do the same thing with sessions.
-* Authlogic::CryptoProviders - Contains various encryption algorithms that Authlogic uses, allowing you to choose your encryption method.
-* Authlogic::I18n - Acts JUST LIKE the rails I18n library, and provides internationalization to Authlogic.
-* Authlogic::Random - A simple class to generate random tokens.
-* Authlogic::TestCase - Various helper methods for testing frameworks to help you test your code.
-* Authlogic::Version - A handy class for determine the version of Authlogic in a number of ways.
+* <b>Authlogic::AuthenticatesMany</b> - Responsible for allowing you to scope sessions to a parent record. Similar to a has_many and belongs_to relationship. This lets you do the same thing with sessions.
+* <b>Authlogic::CryptoProviders</b> - Contains various encryption algorithms that Authlogic uses, allowing you to choose your encryption method.
+* <b>Authlogic::I18n</b> - Acts JUST LIKE the rails I18n library, and provides internationalization to Authlogic.
+* <b>Authlogic::Random</b> - A simple class to generate random tokens.
+* <b>Authlogic::TestCase</b> - Various helper methods for testing frameworks to help you test your code.
+* <b>Authlogic::Version</b> - A handy class for determine the version of Authlogic in a number of ways.
 
-== Quick example
+== Quick Rails example
 
 What if creating sessions worked like an ORM library on the surface...
 
@@ -156,9 +164,7 @@ Or how about persisting the session...
       end
   end
 
-== Install and use
-
-=== 1. Install the gem
+== Install & Use
 
 Install the gem / plugin (recommended)
 
@@ -173,108 +179,32 @@ Or you install this as a plugin (for older versions of rails)
 
   script/plugin install git://github.com/binarylogic/authlogic.git
 
-=== 2. Create your session
-
-Lets assume you are setting up a session for your User model.
-
-Create your user_session.rb file:
-
-  $ script/generate session user_session
-
-This will create a file that looks similar to:
-
-  # app/models/user_session.rb
-  class UserSession < Authlogic::Session::Base
-    # configuration here, see sub modules of Authlogic::Session
-  end
-
-=== 3. Ensure proper database fields
-
-The user model should have the following columns. The names of these columns can be changed with configuration. Better yet, Authlogic tries to guess these names by checking for the existence of common names. See the sub modules of Authlogic::Session for more details, but chances are you won't have to specify any configuration for your field names, even if they aren't the same names as below.
-
-    t.string    :login,               :null => false                # optional, you can use email instead, or both
-    t.string    :crypted_password,    :null => false                # optional, see below
-    t.string    :password_salt,       :null => false                # optional, but highly recommended
-    t.string    :persistence_token,   :null => false                # required
-    t.string    :single_access_token, :null => false                # optional, see Authlogic::Session::Params
-    t.string    :perishable_token,    :null => false                # optional, see Authlogic::Session::Perishability
-    t.integer   :login_count,         :null => false, :default => 0 # optional, see Authlogic::Session::MagicColumns
-    t.integer   :failed_login_count,  :null => false, :default => 0 # optional, see Authlogic::Session::MagicColumns
-    t.datetime  :last_request_at                                    # optional, see Authlogic::Session::MagicColumns
-    t.datetime  :current_login_at                                   # optional, see Authlogic::Session::MagicColumns
-    t.datetime  :last_login_at                                      # optional, see Authlogic::Session::MagicColumns
-    t.string    :current_login_ip                                   # optional, see Authlogic::Session::MagicColumns
-    t.string    :last_login_ip                                      # optional, see Authlogic::Session::MagicColumns
+== Detailed Setup Tutorial
 
-Notice the login and crypted_password fields are optional. If you prefer, you could use OpenID, LDAP, or whatever you want as your main authentication source and not even provide your own authentication system. I recommend providing your own as an option though. Your interface, such as the registration form, can dictate which method is the default. Lastly, adding 3rd party authentication methods should be as easy as installing an Authlogic "add on" gem. See "Authligic add ons" above.
+See the {authlogic example}[http://github.com/binarylogic/authlogic_example/tree/master] for a detailed setup tutorial. I did this because not only do you have a tutorial to go by, but you have an example app that uses the same tutorial, so you can play around with with the code. If you have problems you can compare the code to see what you are doing differently.
 
-=== 4. Set up your model
+== Testing
 
-Make sure you have a model that you will be authenticating with. Since we are using the User model it should look something like:
+I think one of the best aspects of Authlogic is testing. For one, it cuts out <b>a lot</b> of redundant tests in your applications because Authlogic is already thoroughly tested for you. It doesn't include a bunch of tests into your application, because it comes tested, just like any other library.
 
-  class User < ActiveRecord::Base
-    acts_as_authentic do |c|
-      c.my_config_option = my_value # for available options see documentation in: Authlogic::ActsAsAuthentic
-    end # block optional
-  end
-
-You are all set.
-
-=== 5. Next Steps
-
-Here are some common next steps. They might or might not apply to you. For a complete list of everything Authlogic can do please read the documentation or see the sub module list above.
-
-1. Want to use another encryption algorithm, such as BCrypt? See Authlogic::ActsAsAuthentic::Password::Config
-2. Migrating from restful_authentication? See Authlogic::ActsAsAuthentic::RestfulAuthentication::Config
-3. Want to timeout sessions after a period if inactivity? See Authlogic::Session::Timeout
-4. Need to scope your sessions to an account or parent model? See Authlogic::AuthenticatesMany
-5. Need multiple session types in your app? Check out Authlogic::Session::Id
-6. Need to reset passwords or activate accounts? Use the perishable token. See Authlogic::ActsAsAuthentic::PerishableToken
-7. Need to give API access or access to a private feed? Use basic HTTP auth or authentication by params. See Authlogic::Session::HttpAuth or Authlogic::Session::Params
-8. Need to internationalize your app? See Authlogic::I18n
-9. Need help testing? See the Authlogic::TestCase
-
-== Interested in how it works?
-
-Interested in how all of this all works? Basically a before filter is automatically set in your controller which lets Authlogic know about the current controller object. This "activates" Authlogic and allows Authlogic to set sessions, cookies, login via basic http auth, etc. If you are using your framework in a multiple thread environment, don't worry. I kept that in mind and made this thread safe.
-
-From there it is pretty simple. When you try to create a new session the record is authenticated and then all of the session / cookie magic is done for you. The sky is the limit.
-
-== What's wrong with the current solutions?
-
-You probably don't care, but I think releasing the millionth ruby authentication solution requires a little explanation.
-
-I don't necessarily think the current solutions are "wrong", nor am I saying Authlogic is the answer to your prayers. But, to me, the current solutions were lacking something. Here's what I came up with...
+For example, think about ActiveRecord. You don't test the internals of ActiveRecord, because the creators of ActiveRecord have already tested the internals for you. It wouldn't make sense for ActiveRecord to copy it's hundreds of tests into your applications. The same concept applies to Authlogic. You only need to test code you write that is specific to your application, just like everything else in your application.
 
-=== Generators are messy
+That being said, testing your code that uses Authlogic is easy. Since everyone uses different testing suites, I created a helpful module called Authlogic::TestCase, which is basically a set of tools for testing code using Authlogic. I explain testing Authlogic thoroughly in the {Authlogic::TestCase section of the documentation}[http://authlogic.rubyforge.org/classes/Authlogic/TestCase.html]. It should answer any questions you have in regards to testing Authlogic.
 
-Generators have their place, and it is not to add authentication to an app. It doesn't make sense. Generators are meant to be a starting point for repetitive tasks that have no sustainable pattern. Take controllers, the set up is the same thing over and over, but they eventually evolve to a point where there is no clear cut pattern. Trying to extract a pattern out into a library would be extremely hard, messy, and overly complicated. As a result, generators make sense here.
+== Tell me quickly how Authlogic works
 
-Authentication is a one time set up process for your app. It's the same thing over and over and the pattern never really changes. The only time it changes is to conform with newer / stricter security techniques. This is exactly why generators should not be an authentication solution. Generators add code to your application, once code crosses that line, you are responsible for maintaining it. You get to make sure it stays up with the latest and greatest security techniques. And when the plugin you used releases some major update, you can't just re-run the generator, you get to sift through the code to see what changed. You don't really have a choice either, because you can't ignore security updates.
+Interested in how all of this all works? Think about an ActiveRecord model. A database connection must be established before you can use it. In the case of Authlogic, a controller connection must be established before you can use it. It uses that controller connection to modify cookies, the current session, login with HTTP basic, etc. It connects to the controller through a before filter that is automatically set in your controller which lets Authlogic know about the current controller object. Then Authlogic leverages that to do everything, it's a pretty simple design.
 
-Using a library that hundreds of other people use has it advantages. Probably one of the biggest advantages if that you get to benefit from other people using the same code. When Bob in California figures out a new awesome security technique and adds it into Authlogic, you get to benefit from that with a single update. The catch is that this benefit is limited to code that is not "generated" or added into your app. As I said above, once code is "generated" and added into your app, it's your responsibility.
+== What sets Authlogic apart and why I created it
 
-Lastly, there is a pattern here, why clutter up all of your applications with the same code over and over?
-
-=== Security gets outdated
-
-Just as I stated in the above section, you can't stay up to date with your security since the code is generated and updating the plugin does nothing. If there is one thing you should stay up to date with, it's security. But it's not just the fact that there is no reasonable method for receiving updates. It's the fact that they tie you down to an encryption algorithm *AND* they use a bad one at that. Every single solution I've seen uses Sha1, which is joining the party with MD5. Sha1 is not as secure as it used to be. But that's the nature of algorithms, they eventually get phased out, which is fine. Everyone knows this, why not accommodate for this? Authlogic does this with the :transition_from_crypto_provider option. It takes care of transitioning all of your users to a new algorithm. Even better, it provides BCrypt as an option which should, in theory, never require you to switch since you can adjust the cost and make the encryption stronger. At the same time, still compatible with older passwords using the lower cost.
-
-=== Why test the same code over and over?
-
-I've noticed my apps get cluttered with authentication tests, and they are the same exact tests! This irritates me. When you have identical tests across your apps thats a red flag that code can be extracted into a library. What's great about Authlogic is that I tested it for you. You don't write tests that test the internals of ActiveRecord do you? The same applies for Authlogic. Only test code that you've written. Essentially testing authentication is similar to testing any another RESTful controller. This makes your tests focused and easier to understand.
-
-=== Limited to a single authentication
-
-I recently had an app where you could log in as a user and also log in as an employee. I won't go into the specifics of the app, but it made the most sense to do it this way. So I had two sessions in one app. None of the current solutions I found easily supported this. They all assumed a single session. One session was messy enough, adding another just put me over the edge and eventually forced me to write Authlogic. Authlogic can support 100 different sessions easily and in a clean format. Just like an app can support 100 different models and 100 different records of each model.
-
-=== Too presumptuous
-
-A lot of them forced me to name my password column as "this", or the key of my cookie had to be "this". They were a little too presumptuous. I am probably overly picky, but little details like that should be configurable. This also made it very hard to implement into an existing app.
-
-=== Disclaimer
+What inspired me to create Authlogic was the messiness of the current authentication solutions. Put simply, they just didn't feel right, because the logic was not organized properly. As you may know, a common misconception with the MVC design pattern is that the model "M" is only for data access logic, which is wrong. A model is a place for domain logic. This is why the RESTful design pattern and the current authentication solutions don't play nice. Authlogic solves this by placing the session maintenance logic into its own domain (aka "model"). Moving session maintenance into its own domain has its benefits:
 
-I am not trying to  "bash" any other authentication solutions. These are just my opinions, formulate your own opinion. I released Authlogic because I was "scratching my own itch". It has made my life easier and I enjoy using it, hopefully it does the same for you.
+1. <b>It's cleaner.</b> There are no generators in Authlogic. Authlogic provides a class that you can use, it's plain and simple ruby. More importantly, the code in your app is code you write, written the way you want, nice and clean. It's code that should be in your app and is specific to your app, not a redundant authentication pattern.
+2. <b>Easier to stay up-to-date.</b> To make my point, take a look at the commits to any other authentication solution, then look at the {commits for authlogic}[http://github.com/binarylogic/authlogic/commits/master]. How many commits could you easily start using if you already had an app using that solution? With an alternate solution, very few, if any. All of those cool new features and bug fixes are going to have be manually added or wait for your next application. Which is the main reason a generator is not suitable as an authentication solution. With Authlogic you can start using the latest code with a simple update of a gem. No generators, no mess.
+3. <b>It ties everything together on the domain level.</b> Take a new user registration for example, no reason to manually log the user in, authlogic handles this for you via callbacks. The same applies to a user changing their password. Authlogic handles maintaining the session for you.
+4. <b>No redundant tests.</b> Because Authlogic doesn't use generators, #1 also applies to tests. Authlogic is *thoroughly* tested for you. You don't go and test the internals of ActiveRecord in each of your apps do you? So why do the same for Authlogic? Your application tests should be for application specific code. Get rid of the noise and make your tests focused and concise, no reason to copy tests from app to app.
+5. <b>You are not restricted to a single session.</b> Think about Apple's me.com, where they need you to authenticate a second time before changing your billing information. Why not just create a second session for this? It works just like your initial session. Then your billing controller can require an "ultra secure" session.
+6. <b>Easily extendable.</b> One of the distinct advantages of using a library is the ability to use it's API, assuming it has one. Authlogic has an *excellent* public API, meaning it can easily be extended and grow beyond the core library. Checkout the "add ons" list above to see what I mean.
 
 
-Copyright (c) 2009 {Ben Johnson of Binary Logic}(http://www.binarylogic.com), released under the MIT license
+Copyright (c) 2009 {Ben Johnson of Binary Logic}[http://www.binarylogic.com], released under the MIT license

data/lib/authlogic/acts_as_authentic/email.rb

@@ -34,6 +34,10 @@ module Authlogic
         
         # A hash of options for the validates_length_of call for the email field. Allows you to change this however you want.
         #
+        # <b>Keep in mind this is ruby. I wanted to keep this as flexible as possible, so you can completely replace the hash or
+        # merge options into it. Checkout the convenience function merge_validates_length_of_email_field_options to merge
+        # options.</b>
+        #
         # * <tt>Default:</tt> {:within => 6..100}
         # * <tt>Accepts:</tt> Hash of options accepted by validates_length_of
         def validates_length_of_email_field_options(value = nil)
@@ -41,8 +45,23 @@ module Authlogic
         end
         alias_method :validates_length_of_email_field_options=, :validates_length_of_email_field_options
         
+        # A convenience function to merge options into the validates_length_of_email_field_options. So intead of:
+        #
+        #   self.validates_length_of_email_field_options = validates_length_of_email_field_options.merge(:my_option => my_value)
+        #
+        # You can do this:
+        #
+        #   merge_validates_length_of_email_field_options :my_option => my_value
+        def merge_validates_length_of_email_field_options(options = {})
+          self.validates_length_of_email_field_options = validates_length_of_email_field_options.merge(options)
+        end
+        
         # A hash of options for the validates_format_of call for the email field. Allows you to change this however you want.
         #
+        # <b>Keep in mind this is ruby. I wanted to keep this as flexible as possible, so you can completely replace the hash or
+        # merge options into it. Checkout the convenience function merge_validates_format_of_email_field_options to merge
+        # options.</b>
+        #
         # * <tt>Default:</tt> {:with => email_regex, :message => I18n.t('error_messages.email_invalid', :default => "should look like an email address.")}
         # * <tt>Accepts:</tt> Hash of options accepted by validates_format_of
         def validates_format_of_email_field_options(value = nil)
@@ -50,8 +69,17 @@ module Authlogic
         end
         alias_method :validates_format_of_email_field_options=, :validates_format_of_email_field_options
         
+        # See merge_validates_length_of_email_field_options. The same thing except for validates_format_of_email_field_options.
+        def merge_validates_format_of_email_field_options(options = {})
+          self.validates_format_of_email_field_options = validates_format_of_email_field_options.merge(options)
+        end
+        
         # A hash of options for the validates_uniqueness_of call for the email field. Allows you to change this however you want.
         #
+        # <b>Keep in mind this is ruby. I wanted to keep this as flexible as possible, so you can completely replace the hash or
+        # merge options into it. Checkout the convenience function merge_validates_uniqueness_of_email_field_options to merge
+        # options.</b>
+        #
         # * <tt>Default:</tt> {:case_sensitive => false, :scope => validations_scope, :if => "#{email_field}_changed?".to_sym}
         # * <tt>Accepts:</tt> Hash of options accepted by validates_uniqueness_of
         def validates_uniqueness_of_email_field_options(value = nil)
@@ -59,6 +87,11 @@ module Authlogic
         end
         alias_method :validates_uniqueness_of_email_field_options=, :validates_uniqueness_of_email_field_options
         
+        # See merge_validates_length_of_email_field_options. The same thing except for validates_uniqueness_of_email_field_options.
+        def merge_validates_uniqueness_of_email_field_options(options = {})
+          self.validates_uniqueness_of_email_field_options = validates_uniqueness_of_email_field_options.merge(options)
+        end
+        
         private
           def email_regex
             return @email_regex if @email_regex

data/lib/authlogic/acts_as_authentic/login.rb

@@ -31,24 +31,52 @@ module Authlogic
         
         # A hash of options for the validates_length_of call for the login field. Allows you to change this however you want.
         #
-        # * <tt>Default:</tt> {:within => 6..100}
+        # <b>Keep in mind this is ruby. I wanted to keep this as flexible as possible, so you can completely replace the hash or
+        # merge options into it. Checkout the convenience function merge_validates_length_of_login_field_options to merge
+        # options.</b>
+        #
+        # * <tt>Default:</tt> {:within => 3..100}
         # * <tt>Accepts:</tt> Hash of options accepted by validates_length_of
         def validates_length_of_login_field_options(value = nil)
           config(:validates_length_of_login_field_options, value, {:within => 3..100})
         end
         alias_method :validates_length_of_login_field_options=, :validates_length_of_login_field_options
         
+        # A convenience function to merge options into the validates_length_of_login_field_options. So intead of:
+        #
+        #   self.validates_length_of_login_field_options = validates_length_of_login_field_options.merge(:my_option => my_value)
+        #
+        # You can do this:
+        #
+        #   merge_validates_length_of_login_field_options :my_option => my_value
+        def merge_validates_length_of_login_field_options(options = {})
+          self.validates_length_of_login_field_options = validates_length_of_login_field_options.merge(options)
+        end
+        
         # A hash of options for the validates_format_of call for the login field. Allows you to change this however you want.
         #
+        # <b>Keep in mind this is ruby. I wanted to keep this as flexible as possible, so you can completely replace the hash or
+        # merge options into it. Checkout the convenience function merge_validates_format_of_login_field_options to merge
+        # options.</b>
+        #
         # * <tt>Default:</tt> {:with => /\A\w[\w\.\-_@ ]+\z/, :message => I18n.t('error_messages.login_invalid', :default => "should use only letters, numbers, spaces, and .-_@ please.")}
         # * <tt>Accepts:</tt> Hash of options accepted by validates_format_of
         def validates_format_of_login_field_options(value = nil)
-          config(:validates_format_of_login_field_options, value, {:with => /\A\w[\w\.\-_@ ]+\z/, :message => I18n.t('error_messages.login_invalid', :default => "should use only letters, numbers, spaces, and .-_@ please.")})
+          config(:validates_format_of_login_field_options, value, {:with => /\A\w[\w\.+-_@ ]+\z/, :message => I18n.t('error_messages.login_invalid', :default => "should use only letters, numbers, spaces, and .-_@ please.")})
         end
         alias_method :validates_format_of_login_field_options=, :validates_format_of_login_field_options
         
+        # See merge_validates_length_of_login_field_options. The same thing, except for validates_format_of_login_field_options
+        def merge_validates_format_of_login_field_options(options = {})
+          self.validates_format_of_login_field_options = validates_format_of_login_field_options.merge(options)
+        end
+        
         # A hash of options for the validates_uniqueness_of call for the login field. Allows you to change this however you want.
         #
+        # <b>Keep in mind this is ruby. I wanted to keep this as flexible as possible, so you can completely replace the hash or
+        # merge options into it. Checkout the convenience function merge_validates_format_of_login_field_options to merge
+        # options.</b>
+        #
         # * <tt>Default:</tt> {:case_sensitive => false, :scope => validations_scope, :if => "#{login_field}_changed?".to_sym}
         # * <tt>Accepts:</tt> Hash of options accepted by validates_uniqueness_of
         def validates_uniqueness_of_login_field_options(value = nil)
@@ -56,6 +84,11 @@ module Authlogic
         end
         alias_method :validates_uniqueness_of_login_field_options=, :validates_uniqueness_of_login_field_options
         
+        # See merge_validates_length_of_login_field_options. The same thing, except for validates_uniqueness_of_login_field_options
+        def merge_validates_uniqueness_of_login_field_options(options = {})
+          self.validates_uniqueness_of_login_field_options = validates_uniqueness_of_login_field_options.merge(options)
+        end
+        
         # This method allows you to find a record with the given login. If you notice, with ActiveRecord you have the
         # validates_uniqueness_of validation function. They give you a :case_sensitive option. I handle this in the same
         # manner that they handle that. If you are using the login field and set false for the :case_sensitive option in