Athentication

Rails
1

Hi,

Can someone point me in a direction where I can learn more about
handling
athentication in a Rails app? I’m thinking about having an administrator
belonging to one or more admin groups. Each admin group having it’s own
set
of privilages that might overlap.

Thanks,
Peter

2

Hi Peter-

I am implementing an authentication system in an app I’m working on,
too. I
started with the SaltedHashLoginGenerator as a start but then modified
it
for my purposes. I basically decided that any login generator would not
be
ideal for my purposes. Rather than working around it, I’d use it as a
base.
The biggest disadvantage to this approach is losing track of updates
with
the main core.

Specifically, I have added AccountGroups which define priviledge
classes.
Each account, then belongs to exactly one AccountGroup.

Jake

From: Peter M. [mailto:[email protected]]
Sent: Thursday, November 10, 2005 12:00 AM
To: [email protected]
Subject: [Rails] Athentication

Hi,

Can someone point me in a direction where I can learn more about
handling
athentication in a Rails app? I’m thinking about having an administrator
belonging to one or more admin groups. Each admin group having it’s own
set
of privilages that might overlap.

Thanks,
Peter

3

Hi Peter and Jake,
I am implementing a similar scenario on one of the projects I am
working
on.
I am also implementing the same concept of account groups.
Regards
Dibya P.

4

Is it just me or is the number and variation of the various
login/security
systems a bit disturbing.

The debate on what system to use has been on this list for a long time.
So I
thought I’d add my $0.02 as well :wink: Before I do though, my hat goes off
to
the guys who have written these. There are some clever bits in all of
them.

I have been looking at all the different systems that I have been able
to
find and they are all so different I am hesitant to implement any of
them.
I’m no security expert so I don’t really feal comfortable coding my own
in
case I miss something stupid. The ones that I have tried are

Login Generator - GENERATOR
Salted hash login generator - GENERATOR
Model Security - GENERATOR
Active RBAC - COMPONENT
Login Engine - ENGINE/PLUGIN

These are either too complicated for my purposes, too simple, or 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.

This concerns me that there are so many out there with no common
interfacefor 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.

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)

The configuration setup for ActiveRBAC is very complicated and I have to
mash the download (I’m on windows so no links) every different app I
want to
put it into.

I like the idea of the engine/plugin. I can extend the model and
controllers
to suit my app without upsetting the base install, and I can also update
it
whenever I need/want to. Unfortunately the login engine is a bit simple
at
the moment for many applications. Also, without an agreed/enforced
interface
for these systems, I cannot make the plugin swappable if I want to
change.
Say I want 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.

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.

Cheers
Dan

5

My £0.02 (not intentionally of greater value than $0.02 - that’s just
economics + geography! :wink: ) –

I would LOVE (let me reiterate that in capital letters again - LOVE)
people to contribute to the login engine. It’s missing features,
certainly, and there are always bugs appearing in it too: one of my
main motivations for making engines public was the hope that it would
enable people to extend and fix it in a much more transparent way that
generators allow.

If you feel that the login engine isn’t enough for you, it’s quite
easily extendable. I hope to soon be in the position of releasing the
‘user engine’ (name subject to change), which builds roles and
permissions on top of the existing login engine whilst reusing as much
of that existing code as possible. So that should provide a means for
people to ‘upgrade’ their user control without too much hassle. I hope
that once that gets thrown out to the wolves that people will tear it
apart, test it to death and if I’m very very lucky, submit patches and
work together to improve it and make it more robust.

Please do get involved in these projects, whichever you feel is most
worthy or best suits your particular development needs/style – the
Rails community can only benefit from having more developers examining
and working on these extremely common and useful application
components.

6

On 11/11/05, James A. [email protected] wrote:

Please do get involved in these projects, whichever you feel is most
worthy or best suits your particular development needs/style – the
Rails community can only benefit from having more developers examining
and working on these extremely common and useful application
components.

James,

It’s not that I don’t feel that any of these projects aren’t worthy…
far
from it, I think they all have merit and lots of it, It’s just that I’m
very
frustrated at which one to use.

I’m more than happy to contribute in any way that I can… It’s just
that
I’m not sure, at my skill level how I can do that.

7

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
login engine.

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
engine.

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
configuration file.

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 :slight_smile:

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
engine projects.

8

On Thu, Nov 10, 2005 at 11:49:23PM +0000, James A. wrote:

I would LOVE (let me reiterate that in capital letters again - LOVE)
people to contribute to the login engine. It’s missing features,
certainly, and there are always bugs appearing in it too: one of my
main motivations for making engines public was the hope that it would
enable people to extend and fix it in a much more transparent way that
generators allow.

Well, that’s good news for me. :slight_smile:

http://keegan.thebasement.org/articles/2005/11/09/logging-in-with-rails

If you feel that the login engine isn’t enough for you, it’s quite
easily extendable. I hope to soon be in the position of releasing the
‘user engine’ (name subject to change), which builds roles and
permissions on top of the existing login engine whilst reusing as much
of that existing code as possible. So that should provide a means for
people to ‘upgrade’ their user control without too much hassle. I hope
that once that gets thrown out to the wolves that people will tear it
apart, test it to death and if I’m very very lucky, submit patches and
work together to improve it and make it more robust.

I need roles functionality ASAP, and was planning on integrating that
with the LoginEngine, as noted in the post above. Glad to hear you’re
working on this. The sooner the release, the better…

Another problem that has been on my mind regarding this topic is the
need
for a user administration system. If you think UserEngine (RoleEngine?)
should be seperate from LoginEngine, perhaps something like AdminEngine
should also be a different engine?

Thanks!

9

On 11/11/05, Keegan Q. [email protected] wrote:

http://keegan.thebasement.org/articles/2005/11/09/logging-in-with-rails

If you have notes about problems, can you write them up and either
email them to me or create Tickets on the Trac page? :slight_smile:

I need roles functionality ASAP, and was planning on integrating that
with the LoginEngine, as noted in the post above. Glad to hear you’re
working on this. The sooner the release, the better…

It will be next week before what I’ve done sees the light of day, and
you’re not going to be amazed by it. That said, I’m happy to throw it
out there for people to criticise it to death. Perhaps at least then
people might see one way of ‘layering’ engines that isn’t the
nightmare that certain luminaries fear it to be.

Another problem that has been on my mind regarding this topic is the need
for a user administration system. If you think UserEngine (RoleEngine?)
should be seperate from LoginEngine, perhaps something like AdminEngine
should also be a different engine?

The only reason that the ‘UserEngine’ doesn’t completely subsume the
LoginEngine is because it would be a waste of development effort to
fix bugs in the common code between them. I’m not sure how this would
play out between what in your mind is distinct between the role
additions, and an administration interface.

What do you think you should have in an administration interface?

There’s a bit of a storm in engines-land at the moment, but hopefully
we’ll see some good stuff come out of it that benefits everyone. In
the meantime, please keep me updated about your thoughts and progress

  • great post on your blog!

  • james