On Nov 10, 2005, at 5:43 PM, Liquid wrote:
implement any of them. I’m no security expert so I don’t really
just plain un-updateable. I’ve read on the list that this is the
case for many people who, in the end write their own.
I’m not sure why you find it disturbing that there are several
authentication options, especially when you have noticed that they
vary in purpose and complexity. Look, I agree with you that it would
be nice if there were one that fit the bill for most users. That’s
why I’d encourage you to help with a project like ActiveRBAC or
Also, keep in mind that these were written at various points in RoR’s
evolution. Plugins were not available at the time any of these
authentication systems were started, with the exception of the login
This concerns me that there are so many out there with no common
interface for the simple everyday (almost every app) tasks like
setting filters and handling the login function, roles etc that it
forces people to roll their own, taking these apps further away
from any kind of standard in this area. Not very DRY. If I write
an app around one system, and then decide to use another, I will
most likely have to perform major surgery on my code.
Well, the ActiveRBAC project is really trying to make a standardized
Rails authentication system that everyone can use. It grew out of the
request from lots of people for roles based permissions, and I think
it is clearly an effort to supply code that helps people stick with
the DRY principle. Download it. Test it. Report bugs. Suggest
improvements. Write some code and submit patches for the bugs.
In addition to the fact that these login systems do no play
nicely, is that most are geneators. Once I generate it, I almost
certainly need to tailor it for my app, but when I do this, it’s no
longer updateable. This has really made me look elsewhere above
all other problems. If there is a security flaw identified in one
of these systems after implementation, then how the hell, short of
re-writing it do I fix it? (as I said, I’m not a security expert)
Yes, it’s hard to update generated code. But it’s not impossible, and
there have been suggestions on the Wiki about how to isolate your
code from the generated code. In fact, I did this in one of my own
uses of the SHLG and it was actually fairly easy to upgrade. The only
things I generally had to fix were the view templates and the
to start with a light weight system, my site grows in features and
I want to move to something a bit more iron clad, I have to put on
the sugery gloves again. Sort of defeats the purpose of making a
plugin, if similar systems can’t “Plug In” to your app.
Not really. It can be a plugin simply for the purpose of separating
the library from its user, in order to make upgrading the library easy.
Well I’m sorry if I’ve offended anyone with my whinge… As I
said, there are nifty aspects to all these systems as they are.
It’s just at the moment, for me, it’s a case of “Which one will
win” and become the standard (Not talking about in the core). I
don’t really like this idea. I’d rather every system live together
in peace and fill their niches, but I don’t see how that can happen
without some kind of common interface used for the simple things
and each one becoming a plugin/engine.
It’s fine to whine about the generators. I can take it
However, this subject comes up again and again on the list. People
are upset that there isn’t a standard authentication system. But the
fact of the matter is, a core or plugin authentication system is not
going to pop into existence overnight just because people ask for it.
As it stands, most of these systems have been donated by people doing
the work in their spare time. It is going to require everyone who has
a vested interest in seeing a common one available to help out if you
want one that is going to have all the features and simplicity in
system integration that you ask for.
So, I would encourage you to get involved with ActiveRBAC or login