LoginEngine, as the first released engine, tries to bite off a lot -
authentication, a little authorization, user management.
These days, there are better choices for authorization - UserEngine,
Bill
Katz’s plugin, acl_system, etc - and, realistically, most sites will end
up
overriding nearly all the UserController stuff as they build their user
model.
I’d like to take a crack at a stripped-down LoginEngine that ONLY
tackles
authentication (and its related functions, like e-mail verification),
and
doesn’t try to do the rest. For instance, I think changeable_fields is
simultaneously too much (a default authentication engine shouldn’t have
firstname/lastname) and too little (you’ll end up creating your own
model
sooner or later). The UserController is really a scaffold, and should
be
easier to override in small pieces. In general, I feel LoginEngine
wants
to be more modular and orthogonal - and I’m not yet sure exactly what I
mean by that.
My question: do others feel the same way about LoginEngine, in which
case
I’ll submit patches, or should this be a new engine that forks
LoginEngine?
Jay
Hi Jay,
It’s worth noting that the login and user engines tackle different
issues. The login engine provides the login/password authentication,
whereas the user engine (in its current form), only provides an RBAC
layer on top of that.
But anyway… the login engine is simply a port of the Salted Hash
Login Generator, and it suffers from many of the issues which that
generator had. Please do go ahead developing a streamlined version,
and if you feel it’s suitable for other people to use, that’s good too
Hello Jay,
2006/8/16, Jay L. [email protected]:
My question: do others feel the same way about LoginEngine, in which case
I’ll submit patches, or should this be a new engine that forks LoginEngine?
I would fork. That way you can maintain a new version, and if it
becomes more popular, there ya go !
I for one would like to see something simpler. As you say, I almost
always override the views, and some code. I have sometimes wanted to
override what happens when the E-Mail can’t be sent. Couldn’t do it
easily, so I had to copy code. Not very DRY.
Thanks for thinking of this.
Have a nice day !
I’m a strong believer in keeping libraries together. I would say if
there’s any way to upgrade the user/login engines to provide
more/less/better functionality it would be much better than forking.
There are already 16 different login plugins and engines, we really
don’t need another (and it sets yourself up for failure since nobody
will be able to find it in the mess of code).
I’m excited though to see more development on the engine!
Love,
Chuck V.
On Thu, 17 Aug 2006 11:45:21 +0100, James A. wrote:
It’s worth noting that the login and user engines tackle different
issues. The login engine provides the login/password authentication,
whereas the user engine (in its current form), only provides an RBAC
layer on top of that.
Right - but LoginEngine still tries to provide some sort of
authorization
in the form of AuthenticatedSystem. I intend to rip most (all?) of that
out and leave it up to the authorization layer.
But anyway… the login engine is simply a port of the Salted Hash
Login Generator, and it suffers from many of the issues which that
generator had. Please do go ahead developing a streamlined version,
and if you feel it’s suitable for other people to use, that’s good too
Sounds like it should be a separate engine - especially since UserEngine
probably depends on the parts of LoginEngine that I’ll be dismantling,
and
I don’t intend to update UserEngine (I’m using Bill K.'s Authorization
DSL instead).
James, any tips on testing LoginEngine during development? Did you have
a
test-harness application you’d care to share, or did you just create a
database.yml and run it as a first-class application during development?
Seems like repeatedly having to install it into an app would slow down
the
development process.
Jay
On Thu, 17 Aug 2006 21:37:45 -0400, Jay L. wrote:
James, any tips on testing LoginEngine during development? Did you have a
test-harness application you’d care to share, or did you just create a
database.yml and run it as a first-class application during development?
Seems like repeatedly having to install it into an app would slow down the
development process.
I can probably answer that on my own; I’ve become too used to Eclipse,
and
the way Subclipse checks out an entire project at once. The answer is
to
keep a local, blank rails app with just database.yml and the engine
stuff
in environment.rb, and then check out a working copy of your engine to
work
on “in situ”. Sadly, there’s no way to do that with Subclipse, so it’s
back to the command line.
Jay