Rails - Jan 2006 - Why no login modules?

Given all of the login/component controversy, and the multiple
efforts, I''ve really been surprised that no one AFAIK has taken a
module approach to logins / authentication.  It seems that the
generator and engines approaches are the way to go.

I assume this mentality is due to the desire to include login pages,
password recovery pages, etc.  But what if a plugin usage looked like
this:

class MyUser < ActiveRecord::Base
  acts_as_user :login => "username_field", :password =>
"my_password_field"
  use_acl :roles
end

The plugin has no ambitions of handling views, but only doing model
tasks, such as salting the password, and possibly providing access to
roles.  Its easy to update (no generated code), and easy to apply
because it doesn''t place any requirements on the schema or views. 
Maybe it could also provide:

class MyController < ActionController::Base
   authenticate_against :my_user, :except => ["index",
"login"]
end

Goals include simplicity, configurability, no generated code, no view
code, loose coupling to the db schema.  Any feedback as to the merits
of the approach?

--
Kyle Maxwell
Chief Technologist
E Factor Media // FN Interactive
kyle@efactormedia.com
1-866-263-3261

On 1/26/06, Kyle Maxwell <kyle@kylemaxwell.com>
wrote:
> Given all of the login/component controversy, and the multiple
> efforts, I''ve really been surprised that no one AFAIK has taken a
> module approach to logins / authentication.  It seems that the
> generator and engines approaches are the way to go.
>
> I assume this mentality is due to the desire to include login pages,
> password recovery pages, etc.  But what if a plugin usage looked like
> this:
>
> class MyUser < ActiveRecord::Base
>   acts_as_user :login => "username_field", :password =>
"my_password_field"
>   use_acl :roles
> end
>
> The plugin has no ambitions of handling views, but only doing model
> tasks, such as salting the password, and possibly providing access to
> roles.  Its easy to update (no generated code), and easy to apply
> because it doesn''t place any requirements on the schema or views.
> Maybe it could also provide:
>
> class MyController < ActionController::Base
>    authenticate_against :my_user, :except => ["index",
"login"]
> end
>
> Goals include simplicity, configurability, no generated code, no view
> code, loose coupling to the db schema.  Any feedback as to the merits
> of the approach?
>
> --
> Kyle Maxwell
> Chief Technologist
> E Factor Media // FN Interactive
> kyle@efactormedia.com
> 1-866-263-3261
We tried this at RubyConf this year actually (and freaked David out
when showing him what we were working on).  We had an act for the
model (it''s where the acts_as_authenticated name came from) with
plugins for encryption schemes (KirinDave hacked up a nice rot13
one!).  We had controller macros for setting up the various actions
too.  It wasn''t that tough to write really.

The problem was writing all the configuration options.  It became
apparent that we were just substituting the already-clean ruby code
for our own configuration syntax (setting field names, validations,
etc).  Rails is already easy enough to write, and I didn''t feel liking
coming up with something else for the Rails developer to learn in
order to use the plugin.  I then took Tobi''s expert example and
rewrote everything as a straightforward generator.

Anyways, good luck :)

--
Rick Olson
http://techno-weenie.net