Roll your own authentication?

[Linus Pettersson]

Hi!

I watched this video the other day: http://vimeo.com/39498553

where they argue that it may be a better idea to roll your own authentication solution using has_secure_password instead of using, for instance, Devise.

I started a new project using Rails 4 today and need authentication. I'm thinking about creating my own using has_secure_password for learning purposes and also to make it more customizable (not sure what I actually need yet).

Anyway, what are your thoughts on this subject? Do you usually use gems like Devise or just use your own solutions?

// Linus

[Javier Quarite]

As a practice I've done my own authentication methods following a railscast (http://railscasts.com/episodes/250-authentication-from-scratch), but I'm using devise in other apps. 

I've heard that warden (devise is based on that) should be enough for everyone who wants an authentication solution but I'm happy with how devise handles everything

[tamouse mailing lists]

Authentication and authorization are often vital functions; rolling my
own would be interesting as an exercise, but I would rather rely on
something that has seen thousands of uses across as many projects and
eyes. Implementing my own, I also have to create all the tests, and
the chance of me forgetting something in that case are great.

[Linus Pettersson]

Absolutely, that's a valid argument. However, if you need to do some customizations and start monkey patching a gem you may open it up for vulnerabilities as well, right? Plus, it would make your code messy when you have some code in your project and some in the gem.

But sure, it is convient to have everything done and tested for you in gems like Devise.

Any other thoughts on this subject?

[Paul]

+ for Devise

I don't want to do all the work that has already been done for me by the Devise authors.

I always generate the views and modify them to suit, and I generally create a partial to handle whatever login/logout/account settings links I need, but other than that, when writing a standard rails app, it has always done everything just how I'd want it.

That has the added benefit that I don't need to explain the authentication system to anyone else.

An exception is when I'm wrote an offline, single page app. I had to do enough customizing that I probably would have been better off doing something from scratch.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/p9c0G-vFFOIJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[tamouse mailing lists]

On Tue, May 7, 2013 at 2:06 PM, Linus Pettersson

On Tue, May 7, 2013 at 2:06 PM, Linus Pettersson
<linus.pe...@gmail.com> wrote:
> Absolutely, that's a valid argument. However, if you need to do some
> customizations and start monkey patching a gem you may open it up for
> vulnerabilities as well, right? Plus, it would make your code messy when you
> have some code in your project and some in the gem.

I wouldn't approach it this way. Since Devise provides the core
functions I need, I would wrap it up in a Class/Module that abstracts
the Devise parts while implementing my custom/application-specific
parts. Open classing (monkey patching) leaves one in a place where
upgrading Gems becomes exceedingly difficult, and causes confusion to
future maintainers, developers and testers when confronted with such
things.