# Athentication

**URL:** <https://www.ruby-forum.com/t/athentication/94308>\
**Category:** Rails\
**Created:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308 "2005-11-12T12:49:44Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/1 "2005-11-12T12:49:44Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/2 "2005-11-12T12:49:44Z")

</div>

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:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)]  
Sent: Thursday, November 10, 2005 12:00 AM  
To: removed\_email\_address@domain.invalid  
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

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/3 "2005-11-12T12:49:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/4 "2005-11-12T12:49:53Z")

</div>

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 😉 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

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/5 "2005-11-12T12:49:54Z")

</div>

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

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.

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/6 "2005-11-12T12:49:54Z")

</div>

On 11/11/05, James A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:49pm UTC](https://www.ruby-forum.com/t/athentication/94308/7 "2005-11-12T12:49:54Z")

</div>

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 🙂

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.

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:50pm UTC](https://www.ruby-forum.com/t/athentication/94308/8 "2005-11-12T12:50:08Z")

</div>

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

[http://keegan.thebasement.org/articles/2005/11/09/logging-in-with-rails](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!

---

<div class="post-metadata">

**Author:** ![petermichaux](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/46a35a/32.png) [@petermichaux](https://www.ruby-forum.com/u/petermichaux)\
**Post date:** [November 12, 2005, 12:50pm UTC](https://www.ruby-forum.com/t/athentication/94308/9 "2005-11-12T12:50:11Z")

</div>

On 11/11/05, Keegan Q. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> [http://keegan.thebasement.org/articles/2005/11/09/logging-in-with-rails](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? 🙂

> 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