authlogic 2.0.1 → 2.1.2

data/.gitignore

@@ -0,0 +1,9 @@
+.DS_Store
+.swp
+*.log
+*.sqlite3
+pkg/*
+coverage/*
+doc/*
+benchmarks/*
+

data/CHANGELOG.rdoc

@@ -1,4 +1,113 @@
-== 2.0.1
+== 2.1.2
+
+* Return the newly create object for the class level create method, instead of a boolean
+* Add a model_name class method for Authlogic::Session for rails 3 compatibility. Will be using ActiveModel eventually, but this should be a quick fix.
+
+== 2.1.1 released 2009-7-04
+
+* Use mb_chars when downcasing the login string to support international characters.
+* Check for the existence of the :remember_me key before setting remember_me off of a hash.
+* Added check to make sure Authlogic is not loaded too late, causing a NotActivated error.
+
+== 2.1.0 released 2009-6-27
+
+* Fixed bug when using act_like_restful_authentication and setting passwords, needed to add a 2nd parameter to tell if to check against the database or not.
+* Don't save record if they are read only.
+
+== 2.0.14 released 2009-6-13
+
+* Fixed issue with using brute force protection AND generalize_credentials_error_messages. Brute force protection was looking to see if there were password errors, which generalize_credentials_error_messages was obfuscating.
+* Added db_setup? method to avoid errors during rake tasks where the db might not be set up. Ex: migrations
+* Stop using errors.on(key) since that is now deprecated in Rails. Use errors[key] instead.
+* Use valid_password? for the method name to validate a password instead of valid_#{password_field}?.
+
+== 2.0.13 released 2009-5-13
+
+* Add authlogic/regex.rb to manifest
+
+== 2.0.12 released 2009-5-13
+
+* Added the ability to add a last_request_update_allowed? method in your controller to pragmatically tell Authlogic when and when not to update the last_request_at field in your database. This only takes effect if the method if present.
+* Extracted Authlogic's regular expressions into it's own module to allow easy use of them outside of Authlogic. See Authlogic::Regex for more info.
+* Made being_brute_force_protected? true for the Authlogic::Session::BruteForceProtection module.
+* Added the configuration option generalize_credentials_error_messages for the Authlogic::Session::Password module. This allows you to generalize your login / password errors messages as to not reveal was the problem was when authenticating. If enabled, when an invalid login is supplied it will use the same exact error message when an invalid password is supplied.
+* Update email regular expression to use A-Z0-9 instead of /w as to not allow for diacritical marks in an email address.
+* Changed config() convenience method to rw_config() to be more descriptive and less vague.
+
+== 2.0.11 released 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 released 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 released 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.
+* Fixed bug where the find_with_login method was not being aliased if you were using an alternate field besides login.
+
+== 2.0.8 release 2009-4-9
+
+* Dont reset the @password_changed instance variable to false because its halts the callback chain, instead reset it to nil.
+
+== 2.0.7 released 2009-4-9
+
+* Rename TestCase::ControllerAdapter to TestCase::RailsRequestAdapter to help clarify it's usage and fix a constant typo.
+
+== 2.0.6 released 2009-4-9
+
+* 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
+* Use MockCookieJar in tests instead of a Hash in the MockController.
+* Cookies now store the record id as well, for faster lookup. Also to avoid the need to use sessions since sessions are lazily loaded in rails 2.3+
+* Add configuration option for Authlogic::ActsAsAuthentic: ignore_blank_passwords
+* Fix cookie_domain in rails adapter
+* Make password and login fields optional. This allows you to have an alternate authentication method as your main authentication source. Such as OpenID, LDAP, or whatever you want.
+* Reset the @password_changed instance variable after the record has been saved.
+* Add referer and user_agent to mock requests for testing purposes.
+* Add :case_sensitive => false to validates_uniqueness_of calls on the login and email fields.
+* MockRequest not tries to use controller.env['REMOTE_ADDR'] for the IP address in tests.
+* Add in custom find_with_email and find_with_login methods to perform case insensitive searches for databases that are case sensitive by default. This is only done if the :case_insensitive option for validates_uniqueness_of_login_field_options or validates_uniqueness_of_email_field_options is set to false. Which, as of this version, it is. If you are using MySQL this has been the default behavior all along. If you are using SQLite or Postgres this has NOT been the default behavior.
+* Added in exception explaining that you are using the old configuration for acts_as_authentic with an example of the new format.
+
+== 2.0.5 released 2009-3-30
+
+* Stub out authenticate_with_http_basic for TestCase::ControllerAdapter.
+* Added second parameter for add_acts_as_authentic module to specify the position: append or prepend.
+
+== 2.0.4 released 2009-3-28
+
+* Added validates_uniqueness_of_login_field_options and validates_uniqueness_of_email_field_options configuration options
+* Add in checks to make sure session_class is not nil.
+* Cleaned up TestCase some more and added functionality to log users in during functional tests.
+
+== 2.0.3 released 2009-3-26
+
+* Fixed error where default session class does not exist.
+* Fixed human_name for the model to use its own human name and not delegate to the associated model. Translation should be under authlogic.models.user_session (or whatever the name of your session is).
+* Fixed human_attribute_name to use Authlogic keys for translation instead of ActiveRecord: authlogic.attributes.user_session.login
+* For transitioning from restful_authentication, set the REST_AUTH_SITE_KEY to '' if it doesn't exist, instead of nil.
+* Completely rewrote Authlogic::Testing, it's now called Authlogic::TestCase. Testing Authlogic is much easier now. Please see Authlogic::TestCase for more info.
+
+== 2.0.2 released 2009-3-24
+
+* Reset failed_login_count if consecutive_failed_logins_limit has been exceed and the failed_login_ban_for has passed.
+* Update test helpers to use the new configuration scheme.
+* Fixed issue when logging doesn't update last_request_at, so the next persistence try would fail.
+
+== 2.0.1 released 2009-3-23
 
 * Validate length of password.
 * Dont save sessions with a ! during session maintenance.

data/{MIT-LICENSE → LICENSE}

@@ -1,4 +1,4 @@
-Copyright (c) 2007 Ben Johnson of Binary Logic (binarylogic.com)
+Copyright (c) 2009 Ben Johnson of Binary Logic
 
 Permission is hereby granted, free of charge, to any person obtaining
 a copy of this software and associated documentation files (the

data/README.rdoc

@@ -2,93 +2,142 @@
 
 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. They felt wrong 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...
 
-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 top notch. Such as upgrading your hashing algorithm, helping you transition to a new algorithm, etc. Also, Authlogic is a gem, which means you get all of these benefits easily, through a rubygems update.
-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 and focused and free of redundant authentication code from app to app. Meaning generators are *NOT* necessary at all.
-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.
+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:
 
-Authlogic can do all of this and much more, keep reading to see...
+  class UserSession < Authlogic::Session::Base
+    # specify configuration here, such as:
+    # logout_on_timeout true
+    # ...many more options in the documentation
+  end
+
+Log in with any of the following. Create a UserSessionsController and use it just like your other models:
+
+  UserSession.create(:login => "bjohnson", :password => "my password", :remember_me => true)
+  session = UserSession.new(:login => "bjohnson", :password => "my password", :remember_me => true); session.save
+  UserSession.create(:openid_identifier => "identifier", :remember_me => true) # requires the authlogic-oid "add on" gem
+  UserSession.create(my_user_object, true) # skip authentication and log the user in directly, the true means "remember me"
+
+The above handles the entire authentication process for you. It first authenticates, then it sets up the proper session values and cookies to persist the session. Just like you would if you rolled your own authentication solution.
+
+You can also log out / destroy the session:
+
+  session.destroy
+
+After a session has been created, you can persist it across requests. Thus keeping the user logged in:
+
+  session = UserSession.find
+
+To get all of the nice authentication functionality in your model just do this:
+
+  class User < ActiveRecord::Base
+    acts_as_authentic do |c|
+      c.my_config_option = my_value
+    end # the configuration block is optional
+  end
+
+This handles validations, etc. It is also "smart" in the sense that it if a login field is present it will use that to authenticate, if not it will look for an email field, etc. This is all configurable, but for 99% of cases that above is all you will need to do.
+
+Also, sessions are automatically maintained. You can switch this on and off with configuration, but the following will automatically log a user in after a successful registration:
+
+  User.create(params[:user])
+
+This also updates the session when the user changes his/her password.
+
+Authlogic is very flexible, it has a strong public API and a plethora of hooks to allow you to modify behavior and extend it. Check out the helpful links below to dig deeper.
 
 == Helpful links
 
-*	<b>Documentation:</b> http://authlogic.rubyforge.org
-*	<b>Tutorial: Authlogic basic setup:</b> http://www.binarylogic.com/2008/11/3/tutorial-authlogic-basic-setup
-*	<b>Tutorial: Reset passwords with Authlogic the RESTful way:</b> http://www.binarylogic.com/2008/11/16/tutorial-reset-passwords-with-authlogic
-*	<b>Tutorial: Using OpenID with Authlogic:</b> http://www.binarylogic.com/2008/11/21/tutorial-using-openid-with-authlogic
-*	<b>Live example of the tutorials above (with source):</b> http://authlogicexample.binarylogic.com
-*	<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>Documentation:</b> http://rdoc.info/projects/binarylogic/authlogic
+* <b>Repository:</b> http://github.com/binarylogic/authlogic/tree/master
+* <b>Railscasts Screencast:</b> http://railscasts.com/episodes/160-authlogic
+* <b>Live example with OpenID "add on":</b> http://authlogicexample.binarylogic.com
+* <b>Live example repository with tutorial in README:</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>Issues:</b> http://github.com/binarylogic/authlogic/issues
 * <b>Google group:</b> http://groups.google.com/group/authlogic
 
-**Before contacting me, please read:**
-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.
+<b>Before contacting me directly, please read:</b>
+
+If you find a bug or a problem please post it in the issues section. 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
+* <b>Authlogic Facebook Connect:</b> http://github.com/kalasjocke/authlogic_facebook_connect
+* <b>Authlogic OAuth (Twitter):</b> http://github.com/jrallison/authlogic_oauth
+
+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
+== Session bugs (please read if you are having issues with logging in / out)
 
-You can find anything you want about Authlogic in the documentation, all that you need to do is understand the basic design behind it.
+Apparently there is a bug with apache / passenger for v2.1.X with sessions not working properly. This is most likely your problem if you are having trouble logging in / out. This is *not* an Authlogic issue. This can be solved by updating passener or using an alternative session store solution, such as active record store.
 
-That being said, Authlogic is split into 2 main parts:
+== Documentation explanation
 
-  1. Authlogic::Session, which manages sessions.
-  2. Authlogic::ActsAsAuthentic, which adds in functionality to your ActiveRecord model.
+You can find anything you want about Authlogic in the {documentation}[http://authlogic.rubyforge.org], all that you need to do is understand the basic design behind it.
 
-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.
+That being said, there are 2 models involved during authentication. Your Authlogic model and your ActiveRecord model:
 
-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.
+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.
+
+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, last_request_at, 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 automatic session maintenance. EX: a new user registers, automatically log them in. Or a user changes their password, update their session.
+* <b>Authlogic::ActsAsAuthentic::SingleAccessToken</b> - Handles maintaining the single access token.
+* <b>Authlogic::ActsAsAuthentic::ValidationsScope</b> - Allows you to scope all 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 login attempted.
-* Authlogic::Session::Callbacks - Your tools to extend Authlogic, lets you hook in and add/modify behavior, on top of overriding methods.
-* 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.
-* 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.
-* 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 directly.
+* <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::Testing - 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::Regex</b> - Contains regular expressions used in Authlogic. Such as those to validate the format of the log or email.
+* <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...
 
@@ -146,123 +195,51 @@ Or how about persisting the session...
       end
   end
 
-== Install and use
-
-=== 1. Install the gem
+== Install & Use
 
 Install the gem / plugin (recommended)
 
-  $ sudo gem install authlogic
-
-Now add the gem dependency in your config:
-
-  # config/environment.rb
-  config.gem "authlogic"
-
-Or you install this as a plugin (for older versions of rails)
+From rubyforge:
 
-  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
-    t.string    :password_salt,       :null => false                # optional, but highly recommended
-    t.string    :persistence_token,   :null => false
-    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
-
-=== 4. Set up your model
-
-Make sure you have a model that you will be authenticating with. Since we are using the User model it should look something like:
-
-  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::Testing
-
-== 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.
+  $ sudo gem install authlogic
 
-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...
+Or from github:
 
-=== Generators are messy
+  $ sudo gem install binarylogic-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.
+Now just add the gem dependency in your projects configuration.
 
-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.
+Or you can install this as a plugin:
 
-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.
+  script/plugin install git://github.com/binarylogic/authlogic.git
 
-Lastly, there is a pattern here, why clutter up all of your applications with the same code over and over?
+== Detailed Setup Tutorial
 
-=== Security gets outdated
+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.
 
-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.
+== Testing
 
-=== Why test the same code over and over?
+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.
 
-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.
+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.
 
-=== Limited to a single authentication
+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://rdoc.info/rdoc/binarylogic/authlogic/blob/f2f6988d3b97e11770b00b72a7a9733df69ffa5b/Authlogic/TestCase.html]. It should answer any questions you have in regards to testing Authlogic.
 
-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.
+== Tell me quickly how Authlogic works
 
-=== Too presumptuous
+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. Nothing crazy going on, Authlogic is just leveraging the tools your framework provides in the controller object.
 
-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.
+== What sets Authlogic apart and why I created it
 
-=== 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>Framework agnostic</b>. Authlogic can be used in *any* ruby framework you want: Rails, Merb, Sinatra, Mack, your own framework, whatever. It's not tied down to Rails. It does this by abstracting itself from these framework's controllers by using a controller adapter. Thanks to {Rack}[http://rack.rubyforge.org/], there is a defined standard for controller structure, and that's what Authlogic's abstract adapter follows. So if your controller follows the rack standards, you don't need to do anything. Any place it deviates from this is solved by a simple adapter for your framework that closes these gaps. For an example, checkout the Authlogic::ControllerAdapters::MerbAdapter.
+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 its 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) 2008 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/Rakefile

@@ -1,21 +1,42 @@
-ENV['RDOCOPT'] = "-S -f html -T hanna"
+require 'rubygems'
+require 'rake'
 
-require "rubygems"
-require "hoe"
-require File.dirname(__FILE__) << "/lib/authlogic/version"
+begin
+  require 'jeweler'
+  Jeweler::Tasks.new do |gem|
+    gem.name = "authlogic"
+    gem.summary = "A clean, simple, and unobtrusive ruby authentication solution."
+    gem.email = "bjohnson@binarylogic.com"
+    gem.homepage = "http://github.com/binarylogic/authlogic"
+    gem.authors = ["Ben Johnson of Binary Logic"]
+    gem.rubyforge_project = "authlogic"
+    gem.add_dependency "activesupport"
+  end
+  Jeweler::RubyforgeTasks.new
+rescue LoadError
+  puts "Jeweler (or a dependency) not available. Install it with: sudo gem install jeweler"
+end
 
-Hoe.new("Authlogic", Authlogic::Version::STRING) do |p|
-  p.name = "authlogic"
-  p.author = "Ben Johnson of Binary Logic"
-  p.email  = 'bjohnson@binarylogic.com'
-  p.summary = "A clean, simple, and unobtrusive ruby authentication solution."
-  p.description = "A clean, simple, and unobtrusive ruby authentication solution."
-  p.url = "http://github.com/binarylogic/authlogic"
-  p.history_file = "CHANGELOG.rdoc"
-  p.readme_file = "README.rdoc"
-  p.extra_rdoc_files = ["CHANGELOG.rdoc", "README.rdoc"]
-  p.remote_rdoc_dir = ''
-  p.test_globs = ["test/*/test_*.rb", "test/*/*_test.rb"]
-  p.extra_deps = %w(activesupport)
-  p.post_install_message = "Version 2.0 introduces some changes that break backwards compatibility. The big change is how acts_as_authentic accepts configuration options. Instead of a hash, it now accepts a block: acts_as_authentic { |c| c.my_config_option = my_value}. See the docs for more details."
-end
+require 'rake/testtask'
+Rake::TestTask.new(:test) do |test|
+  test.libs << 'test'
+  test.pattern = 'test/**/*_test.rb'
+  test.verbose = true
+end
+
+begin
+  require 'rcov/rcovtask'
+  Rcov::RcovTask.new do |test|
+    test.libs << 'test'
+    test.pattern = 'test/**/*_test.rb'
+    test.verbose = true
+  end
+rescue LoadError
+  task :rcov do
+    abort "RCov is not available. In order to run rcov, you must: sudo gem install spicycode-rcov"
+  end
+end
+
+task :test => :check_dependencies
+
+task :default => :test

data/VERSION.yml

@@ -0,0 +1,4 @@
+--- 
+:patch: 2
+:major: 2
+:minor: 1