Rails - May 2006 - Recommendation for a user authentication plugin

Hi,
Which user-authentication plugins should one try first? Too many out 
there and too little time to try them all fairly. Thanks for your 
recommendation.
cheers!

-- 
Posted via http://www.ruby-forum.com/.

The authentication plugin written by Techoweenie seems to be the best 
one out there at the minute. It does just enough without getting in the 
way. It should be on the wiki or in the new plugin repository website.

Cheers

Jonathan
------
http://www.agileevolved.com


Gene Kahn wrote:
> Hi,
> Which user-authentication plugins should one try first? Too many out 
> there and too little time to try them all fairly. Thanks for your 
> recommendation.
> cheers!
>

http://wiki.rubyonrails.org/rails/pages/HowToQuicklyDoAuthenticationWithLoginGenerator

On 5/9/06, Gene Kahn <kublaikhan55@hotmail.com>
wrote:
> Hi,
> Which user-authentication plugins should one try first? Too many out
> there and too little time to try them all fairly. Thanks for your
> recommendation.
> cheers!
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

--
Ben Reubenstein
303-947-0446
http://www.benr75.com

On Tuesday, May 09, 2006, at 8:10 PM, Gene Kahn wrote:
>Hi,
>Which user-authentication plugins should one try first? Too many out
>there and too little time to try them all fairly. Thanks for your
>recommendation.
>cheers!
>
>--
>Posted via http://www.ruby-forum.com/.
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
I would hesitate to make a suggestion without a better understanding of  
what you intend to use it for.  The capabilities of the systems vary  
widely from a simple authentication system to a full blown role-based system.

Take some time to figure out exactly what you need (and may need in the  
future) and then see which one of the plugins does that.

_Kevin

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.

from a command line
> gem install login_generator

this comes with a readme and is relly easy to use.  get you set up in 3 
min..

-- 
Posted via http://www.ruby-forum.com/.

Jon D wrote:
> 
> 
> 
> from a command line
> 
>> gem install login_generator
> 
> 
> this comes with a readme and is relly easy to use.  get you set up in 3 
> min..
Would salted_login_generator be sort of a ''better'' one? Seems
like it is
the one after.

thanks
gk

-- 
Posted via http://www.ruby-forum.com/.

Kevin Olbrich wrote:
> On Tuesday, May 09, 2006, at 8:10 PM, Gene Kahn wrote:
>>Rails@lists.rubyonrails.org
>>http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> I would hesitate to make a suggestion without a better understanding of
> what you intend to use it for.  The capabilities of the systems vary
> widely from a simple authentication system to a full blown role-based 
> system.
> 
> Take some time to figure out exactly what you need (and may need in the
> future) and then see which one of the plugins does that.
> 
> _Kevin
Yeah, a full blown role-based system is what I''m looking for. I just 
gemmed salted_login_generator to take a look.

thanks
gk

-- 
Posted via http://www.ruby-forum.com/.

On May 9, 2006, at 11:43 AM, Gene Kahn wrote:
> Kevin Olbrich wrote:
>> On Tuesday, May 09, 2006, at 8:10 PM, Gene Kahn wrote:
>>> Rails@lists.rubyonrails.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>> I would hesitate to make a suggestion without a better  
>> understanding of
>> what you intend to use it for.  The capabilities of the systems vary
>> widely from a simple authentication system to a full blown role-based
>> system.
>>
>> Take some time to figure out exactly what you need (and may need  
>> in the
>> future) and then see which one of the plugins does that.
>>
>> _Kevin
>
> Yeah, a full blown role-based system is what I''m looking for. I
just
> gemmed salted_login_generator to take a look.
>
> thanks
> gk
>
Do yourself a favor and stay as far away from the salted login  
generator as you can. It''s really caused me a lot of problems in the  
past and I still get to refactor peoples code to get rid of this  
"gem" all the time. acts_as_authenticated is really the best one out  
there so the authentication  part. It is really simnple and just does  
enough to finction and get out of your way. You will have a much  
easier time extending the acts_as_auth to do what you want then with  
most of the other ones.

Although for role based stuff there are many options as well. But  
they are not a one size fits all situation. WHat do you really need  
anyway? Roles? Permissions? Groups? Would just a few simple roles work?

Also I see many people make the mistake of spending a lot of time on  
authentication early on in their projects. Auth is easy, you should  
save it for last and spend your time solving the main problem your  
app will be addressing. Then you can add in auth later. Or auth is  
very easy top mock out and then flesh it out completely later.

-Ezra

Ezra Zygmuntowicz wrote:
> On May 9, 2006, at 11:43 AM, Gene Kahn wrote:
> 
>>>
>> gk
>>
> 
> Do yourself a favor and stay as far away from the salted login
> generator as you can. It''s really caused me a lot of problems in
the
> past and I still get to refactor peoples code to get rid of this
> "gem" all the time. acts_as_authenticated is really the best one
out
> there so the authentication  part. It is really simnple and just does
> enough to finction and get out of your way. You will have a much
> easier time extending the acts_as_auth to do what you want then with
> most of the other ones.
Ok, I''ll take your word for it and look first at acts_as_authenticated 
if it is role-based. The simplest with the functionality you now need -- 
don''t code for the future, as I remember, is an agile advice (but make 
your system as easy to change as possible).
> 
> Also I see many people make the mistake of spending a lot of time on
> authentication early on in their projects. Auth is easy, you should
> save it for last and spend your time solving the main problem your
> app will be addressing. Then you can add in auth later. Or auth is
> very easy top mock out and then flesh it out completely later.
> 
I''m afraid I work from the other end. I lay out the user structure 
first, then work incrementally on functions that I can attach or detach 
from user roles.
The next application is simply more functions (with additional tables in 
the same database) mapped to the user structure. There is just one user 
subsystem, one backend, and a pool of functions in between. I''m willing
to change for a simpler and more flexible architecture though, as 
always.

gk
> -Ezra



-- 
Posted via http://www.ruby-forum.com/.

Hi, I think it may be important for the login functionality to be complete
especially if I''m working for a client that want to see the flow of the
site.  For example,

User Registration Use Case

This use case begins when the user clicks registration button/link.

1)  The system responds by presenting the user with a registration
screen/view.

2)  The user completes the user registration form and clicks submit button.

3)  The system responds by validating the form.

     [ if validation = success ] then

            The system responds by sending a confirmation e-mail to the
user.

     [ else ]

             The system responds by generating the appropriate error
messages to the screen.

     [ end if ]

4)   The user responds by confirming the registration via e-mail.

5)   The system responds enabling the account.

This use case ends when the system presents a successfully activation
message to the user.

Now, the above scenario cannot be achieved unless the necessary
authentication system is in place.  In short, it really depends on what you
need to show to your client(s) and this will dictate when you should deal
with authentication.

-Conrad

On 5/9/06, Gene Kahn <kublaikhan55@hotmail.com>
wrote:
>
> Ezra Zygmuntowicz wrote:
> > On May 9, 2006, at 11:43 AM, Gene Kahn wrote:
> >
> >>>
> >> gk
> >>
> >
> > Do yourself a favor and stay as far away from the salted login
> > generator as you can. It''s really caused me a lot of problems
in the
> > past and I still get to refactor peoples code to get rid of this
> > "gem" all the time. acts_as_authenticated is really the best
one out
> > there so the authentication  part. It is really simnple and just does
> > enough to finction and get out of your way. You will have a much
> > easier time extending the acts_as_auth to do what you want then with
> > most of the other ones.
>
> Ok, I''ll take your word for it and look first at
acts_as_authenticated
> if it is role-based. The simplest with the functionality you now need --
> don''t code for the future, as I remember, is an agile advice (but
make
> your system as easy to change as possible).
> >
> > Also I see many people make the mistake of spending a lot of time on
> > authentication early on in their projects. Auth is easy, you should
> > save it for last and spend your time solving the main problem your
> > app will be addressing. Then you can add in auth later. Or auth is
> > very easy top mock out and then flesh it out completely later.
> >
> I''m afraid I work from the other end. I lay out the user structure
> first, then work incrementally on functions that I can attach or detach
> from user roles.
> The next application is simply more functions (with additional tables in
> the same database) mapped to the user structure. There is just one user
> subsystem, one backend, and a pool of functions in between. I''m
willing
> to change for a simpler and more flexible architecture though, as
> always.
>
> gk
> > -Ezra
>
>
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060509/c2aab3e7/attachment-0001.html