authlogic 0.10.4

data/CHANGELOG.rdoc

@@ -0,0 +1,47 @@
+== 0.10.4 released 2008-10-31
+
+* Changed configuration to use inheritable attributes
+* Cleaned up requires to be in their proper files
+* Added in scope support.
+
+== 0.10.3 released 2008-10-31
+
+* Instead of raising an error when extra fields are passed in credentials=, just ignore them.
+* Added remember_me config option to set the default value.
+* Only call credential methods if an argument was passed.
+* More unit tests
+* Hardened automatic session updating. Also automatically log the user in if they change their password when logged out.
+
+== 0.10.2 released 2008-10-24
+
+* Added in stretches to the default Sha512 encryption algorithm.
+* Use column_names instead of columns when determining if a column is present.
+* Improved validation callbacks. after_validation should only be run if valid? = true. Also clear errors before the "before_validation" callback.
+
+== 0.10.1 released 2008-10-24
+
+* Sessions now store the "remember token" instead of the id. This is much safer and guarantees all "sessions" that are logged in are logged in with a valid password. This way stale sessions can't be persisted.
+* Bumped security to Sha512 from Sha256.
+* Remove attr_protected call in acts_as_authentic
+* protected_password should use pasword_field configuration value
+* changed magic state "inactive" to "active"
+
+== 0.10.0 released 2008-10-24
+
+* Do not allow instantiation if the session has not been activated with a controller object. Just like ActiveRecord won't let you do anything without a DB connection.
+* Abstracted controller implementation to allow for rails, merb, etc adapters. So this is not confined to the rails framework.
+* Removed create and update methods and added save, like ActiveRecord.
+* after_validation should be able to change the result if it adds errors on callbacks.
+* Completed tests.
+
+== 0.9.1 released 2008-10-24
+
+* Changed scope to id. Makes more sense to call it an id and fits better with the ActiveRecord model.
+* Removed saving_from_session flag, apparently it is not needed.
+* Fixed updating sessions to make more sense and be stricter.
+* change last_click_at to last_request_at
+* Only run "after" callbacks if the result is successful.
+
+== 0.9.0 released 2008-10-24
+
+* Initial release.

data/MIT-LICENSE

@@ -0,0 +1,20 @@
+Copyright (c) 2007 Ben Johnson of Binary Logic (binarylogic.com)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/Manifest

@@ -0,0 +1,100 @@
+CHANGELOG.rdoc
+init.rb
+lib/authlogic/active_record/acts_as_authentic.rb
+lib/authlogic/active_record/authenticates_many.rb
+lib/authlogic/active_record/scoped_session.rb
+lib/authlogic/controller_adapters/abstract_adapter.rb
+lib/authlogic/controller_adapters/rails_adapter.rb
+lib/authlogic/session/active_record_trickery.rb
+lib/authlogic/session/base.rb
+lib/authlogic/session/callbacks.rb
+lib/authlogic/session/config.rb
+lib/authlogic/session/errors.rb
+lib/authlogic/sha512_crypto_provider.rb
+lib/authlogic/version.rb
+lib/authlogic.rb
+Manifest
+MIT-LICENSE
+Rakefile
+README.rdoc
+test_app/app/controllers/application.rb
+test_app/app/controllers/companies_controller.rb
+test_app/app/controllers/user_sessions_controller.rb
+test_app/app/controllers/users_controller.rb
+test_app/app/helpers/application_helper.rb
+test_app/app/helpers/companies_helper.rb
+test_app/app/helpers/user_sessions_helper.rb
+test_app/app/helpers/users_helper.rb
+test_app/app/models/company.rb
+test_app/app/models/project.rb
+test_app/app/models/user.rb
+test_app/app/models/user_session.rb
+test_app/app/views/layouts/application.html.erb
+test_app/app/views/user_sessions/new.html.erb
+test_app/app/views/users/_form.erb
+test_app/app/views/users/edit.html.erb
+test_app/app/views/users/new.html.erb
+test_app/app/views/users/show.html.erb
+test_app/config/boot.rb
+test_app/config/database.yml
+test_app/config/environment.rb
+test_app/config/environments/development.rb
+test_app/config/environments/production.rb
+test_app/config/environments/test.rb
+test_app/config/initializers/inflections.rb
+test_app/config/initializers/mime_types.rb
+test_app/config/initializers/new_rails_defaults.rb
+test_app/config/routes.rb
+test_app/db/development.sqlite3
+test_app/db/migrate/20081023040052_create_users.rb
+test_app/db/migrate/20081103003828_create_companies.rb
+test_app/db/migrate/20081103003834_create_projects.rb
+test_app/db/schema.rb
+test_app/db/test.sqlite3
+test_app/doc/README_FOR_APP
+test_app/public/404.html
+test_app/public/422.html
+test_app/public/500.html
+test_app/public/dispatch.cgi
+test_app/public/dispatch.fcgi
+test_app/public/dispatch.rb
+test_app/public/favicon.ico
+test_app/public/images/rails.png
+test_app/public/javascripts/application.js
+test_app/public/javascripts/controls.js
+test_app/public/javascripts/dragdrop.js
+test_app/public/javascripts/effects.js
+test_app/public/javascripts/prototype.js
+test_app/public/robots.txt
+test_app/public/stylesheets/scaffold.css
+test_app/Rakefile
+test_app/README
+test_app/script/about
+test_app/script/console
+test_app/script/dbconsole
+test_app/script/destroy
+test_app/script/generate
+test_app/script/performance/benchmarker
+test_app/script/performance/profiler
+test_app/script/performance/request
+test_app/script/plugin
+test_app/script/process/inspector
+test_app/script/process/reaper
+test_app/script/process/spawner
+test_app/script/runner
+test_app/script/server
+test_app/test/fixtures/companies.yml
+test_app/test/fixtures/projects.yml
+test_app/test/fixtures/users.yml
+test_app/test/functional/companies_controller_test.rb
+test_app/test/functional/user_sessions_controller_test.rb
+test_app/test/functional/users_controller_test.rb
+test_app/test/integration/company_user_session_stories_test.rb
+test_app/test/integration/user_sesion_stories_test.rb
+test_app/test/integration/user_session_config_test.rb
+test_app/test/integration/user_session_test.rb
+test_app/test/test_helper.rb
+test_app/test/unit/account_test.rb
+test_app/test/unit/company_test.rb
+test_app/test/unit/project_test.rb
+test_app/test/unit/user_test.rb

data/README.rdoc

@@ -0,0 +1,292 @@
+= Authlogic
+
+Authlogic is "rails authentication done right". Put simply, its the Chuck Norris of authentication solutions.
+
+The last thing we need is another authentication solution for rails, right? That's what I thought until I tried out some of the current solutions. None of them felt right. They were either too complicated, bloated, littered my application with tons of code, or were just confusing. This is not the simple / elegant rails we all fell in love with. We need a "rails like" authentication solution. Authlogic is my attempt to satisfy that need...
+
+Wouldn't it be nice to keep your app up to date with the latest and greatest security techniques with a simple update of a plugin?
+
+What if you could have authentication up and running in minutes without having to run a generator? All because it's simple, like everything else in rails.
+
+What if creating a user session could be as simple as...
+
+  UserSession.create(params[:user_session])
+
+What if your user sessions controller could look just like your other controllers...
+
+  class UserSessionsController < ApplicationController
+    def new
+      @user_session = UserSession.new
+    end
+    
+    def create
+      @user_session = UserSession.new(params[:user_session])
+      if @user_session.save
+        redirect_to account_url
+      else
+        render :action => :new
+      end
+    end
+    
+    def destroy
+      @user_session.destroy
+    end
+  end
+
+Look familiar? If you didn't know any better, you would think UserSession was an ActiveRecord model. I think that's pretty cool, because it fits nicely into the RESTful development pattern, a style we all know and love. What about the view...
+
+  <%= error_messages_for "user_session" %>
+  <% form_for @user_session do |f| %>
+    <%= f.label :login %><br />
+    <%= f.text_field :login %><br />
+    <br />
+    <%= f.label :password %><br />
+    <%= f.password_field :password %><br />
+    <br />
+    <%= f.submit "Login" %>
+  <% end %>
+
+Or how about persisting the session...
+
+  class ApplicationController
+    before_filter :load_user
+    
+    protected
+      def load_user
+        @user_session = UserSession.find
+        @current_user = @user_session && @user_session.record
+      end
+  end
+
+Authlogic makes this a reality. This is just the tip of the ice berg. Keep reading to find out everything Authlogic can do.
+
+== Helpful links
+
+*	<b>Documentation:</b> http://authlogic.rubyforge.org
+*	<b>Authlogic setup tutorial:</b> coming soon...
+*	<b>Live example of the setup tutorial above (with source):</b> coming soon....
+* <b>Bugs / feature suggestions:</b> http://binarylogic.lighthouseapp.com/projects/18752-authlogic
+
+== Install and use
+
+Install the gem / plugin
+
+  $ sudo gem install authlogic
+  $ cd vendor/plugins
+  $ sudo gem unpack authlogic
+
+Or as a plugin
+
+  script/plugin install git://github.com/binarylogic/authlogic.git
+
+In an effort to keep this readme a reference instead of a step by step guide, I moved the setup tutorial to my blog. See "helpful links" above. If this is your first time using Authlogic checkout the tutorial.
+
+== Magic Columns
+
+Just like ActiveRecord has "magic" columns, such as: created_at and updated_at. Authlogic has its own "magic" columns too:
+
+  Column name           Description
+  login_count           Increased every time an explicit login is made. This will *NOT* increase if logging in by a session, cookie, or basic http auth
+  last_request_at       Updates every time the user logs in, either by explicitly logging in, or logging in by cookie, session, or http auth
+  current_login_at      Updates with the current time when an explicit login is made.
+  last_login_at         Updates with the value of current_login_at before it is reset.
+  current_login_ip      Updates with the request remote_ip when an explicit login is made.
+  last_login_ip         Updates with the value of current_login_ip before it is reset.
+  
+== Magic States
+
+Authlogic tries to check the state of the record before creating the session. If your record responds to the following methods and any of them return false, validation will fail:
+
+  Method name           Description
+  active?               Is the record marked as active?
+  approved?             Has the record been approved?
+  confirmed?            Has the record been conirmed?
+  
+What's neat about this is that these are checked upon any type of login. When logging in explicitly, by cookie, session, or basic http auth. So if you mark a user inactive in the middle of their session they wont be logged back in next time they refresh the page. Giving you complete control.
+
+Need Authlogic to check your own "state"? No problem, check out the hooks section below. Add in a before_validation or after_validation to do your own checking.
+
+== Hooks / Callbacks
+
+Just like ActiveRecord you can create your own hooks / callbacks so that you can do whatever you want when certain actions are performed. Here they are:
+
+  before_create
+  after_create
+  before_destroy
+  after_destroy
+  before_save
+  after_save
+  before_update
+  after_update
+  before_validation
+  after_validation
+  
+== Multiple Sessions / Session Identifiers
+
+You're asking: "why would I want multiple sessions?". Take this example:
+
+You have an app where users login and then need to re-login to view / change their billing information. Similar to how Apple's me.com works. What you could do is have the user login with their normal session, then have an entirely new session that represents their "secure" session. But wait, this is 2 users sessions. No problem:
+
+  # regular user session
+  @user_session = UserSession.new
+  @user_session.id
+  # => nil
+
+  # secure user session
+  @secure_user_session = UserSession.new(:secure)
+  @secure_user_session.id
+  # => :secure
+
+This will keep everything separate. The :secure session will store its info in a separate cookie, separate session, etc. Just set the id and you are good to go. Need to retrieve the session?
+
+  @user_session = UserSession.find
+  @secure_user_session = UserSession.find(:secure)
+
+For more information on ids checkout Authlogic::Session::Base#initialize
+
+== Scoping
+
+Scoping with authentication is a little tricky because it can come in many different flavors:
+
+1. Accounts have many users, meaning users can only belong to one account at a time.
+2. Accounts have and belong to many users, meaning a user can belong to more than one account.
+3. Users access their accounts via subdomains.
+4. Users access their accounts by selecting their account and storing their selection, *NOT* using subdomains. Maybe you store their selection in a session, cookie, or the database. It doesn't matter.
+
+Now mix and match the above, it can get pretty hairy. Fear not, because Authlogic is designed in a manner where it doesn't care how you do it, all that you have to do is break it down. When scoping a session there are 3 parts you might want to scope:
+
+1. The model (the validations, etc)
+2. The session (finding the record)
+3. The cookies (the names of the session key and cookie)
+
+I will describe each below, in order.
+
+=== Scoping your model
+
+This scopes your login field validation, so that users are allowed to have the same login, just not in the same account.
+
+  # app/models/user.rb
+  class User < ActiveRecord::Base
+    acts_as_authentic :scope => :account_id
+  end
+
+=== Scoping your session
+
+When you session tries to validate it searches for a record. You want to scope that search. No problem...
+
+The goal of Authlogic was to not try and introduce anything new. As a result I came up with:
+
+  @account.user_sessions.find
+  @account.user_sessions.create
+  @account.user_sessions.build
+  # ... etc
+
+This works just like ActiveRecord, so it should come natural. Here is how you get this functionality:
+
+  class Account < ActiveRecord::Base
+    authenticates_many :user_sessions
+  end
+
+=== Scoping cookies
+
+What's neat about cookies is that if you use sub domains they automatically scope their self. Meaning if you create a cookie in whatever.yourdomain.com it will not exist in another.yourdomain.com. So if you have the example used above, where you can access accounts via a sub domain, you don't have to do anything.
+
+But what if you don't want to separate your cookies by subdomains? You can accomplish this by doing:
+
+  ActionController::Base.session_options[:session_domain] = ‘.mydomain.com’
+
+If for some reason the above doesn't work for you, do some simple Google searches. There are a million blog posts on this.
+
+Now let's look at this from the other angle. What if you are *NOT* using subdomains, but still want to separate cookies for each account. Simple, set the :scope_cookies option for authenticate_many:
+
+  class Account < ActiveRecord::Base
+    authenticates_many :user_sessions, :scope_cookies => true
+  end
+
+Done, Authlogic will give each cookie a unique name depending on the account.
+
+With the above information you should be able to scope your sessions any way you want. Just mix and match the tools above to accomplish what you want. Also check out the documentation on Authlogic::ActiveRecord::AuthenticatesMany.
+
+== Errors
+
+The errors in Authlogic work JUST LIKE ActiveRecord. In fact, it uses the exact same ActiveRecord errors class. Use it the same way:
+
+  class UserSession
+    before_validation :check_if_awesome
+    
+    private
+      def check_if_awesome
+        errors.add(:login, "must contain awesome") if login && !login.include?("awesome")
+        errors.add_to_base("You must be awesome to log in") unless record.awesome?
+      end
+  end
+
+== Automatic Session Updating
+
+This is one of my favorite features that I think is pretty cool. It's things like this that make a library great and let you know you are on the right track.
+
+Just to clear up any confusion, Authlogic does not store the plain id in the session. It stores a token. This token changes with the password, this way stale sessions can not be persisted.
+
+That being said...What if a user changes their password? You have to re-log them in with the new password, recreate the session, etc, pain in the ass. Or what if a user creates a new user account? You have to do the same thing. Here's an even better one: what if a user is in the admin area and changes his own password? There might even be another place passwords can change. It shouldn't matter, your code should be written in a way where you don't have to remember to do this.
+
+Instead of updating sessions all over the place, doesn't it make sense to do this at a lower level? Like the User model? You're saying "but Ben, models can't mess around with sessions and cookies". True...but Authlogic can, and you can access Authlogic just like a model. I know in most situations it's not good practice to do this but I view this in the same class as sweepers, and feel like it actually is good practice here. User sessions are directly tied to users, they should be connected on the model level.
+
+Fear not, because the acts_as_authentic method you call in your model takes care of this for you, by adding an after_save callback to automatically keep the session up to date. You don't have to worry about it anymore. Don't even think about it. Let your UsersController deal with users, not users *AND* sessions. *ANYTIME* the user changes his password in *ANY* way, his session will be updated.
+
+Here is basically how this is done....
+
+  class User < ActiveRecord::Base
+    after_save :maintain_sessions!
+    after_update :update_sessions!
+    
+    private
+      def maintain_sessions!
+        # If we aren't logged in at all and the password was changed, go ahead and log the user in
+        # If we are logged in and the password has change, update the sessions
+      end
+  end
+
+Obviously there is a little more to it than this, but hopefully this clarifies any confusion. Lastly, this can be altered / disabled via a configuration option. Just set :session_ids => nil when calling acts_as_authentic.
+
+When things come together like this I think its a sign that you are doing something right. Put that in your pipe and smoke it!
+
+== What about [insert framework here]?
+
+As of now, authlogic supports rails right out of the box. But I designed authlogic to be framework agnostic. The only thing stopping Authlogic from being implemented in merb, or any other framework, is a simple adapter. I have not had the opportunity to use Authlogic in anything other than rails. If you want to use this in merb or any other framework take a look at authlogic/controller/rails_adapter.rb. 
+
+== 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 rails 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 authentication solution for a framework that has been around for over 4 years 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...
+
+=== Generators are messy
+
+Generators have their place, and it is not to add authentication to a rails 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.
+
+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.
+
+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.
+
+Lastly, there is a pattern here, why clutter up all of your applications with the same code over and over?
+
+=== 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
+
+I am not trying to  "bash" any other authentication solutions. These are just my opinions, formulate your own opinion. I released Authlogic because it has made my life easier and I enjoy using it, hopefully it does the same for you.
+
+
+Copyright (c) 2008 Ben Johnson of [Binary Logic](http://www.binarylogic.com), released under the MIT license