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
As a practice I’ve done my own authentication methods following a
railscast
(#250 Authentication from Scratch - RailsCasts),
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
On Mon, May 6, 2013 at 12:38 PM, Linus P.
[email protected] wrote:
need yet).
Anyway, what are your thoughts on this subject? Do you usually use gems like
Devise or just use your own solutions?
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.
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?
Den tisdagen den 7:e maj 2013 kl. 03:56:33 UTC+2 skrev tamouse:
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.
On Tue, May 7, 2013 at 3:06 PM, Linus P.
<[email protected]
On Tue, May 7, 2013 at 2:06 PM, Linus P.
[email protected] wrote:
instance, Devise.
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.
On Tue, May 7, 2013 at 2:06 PM, Linus P.
[email protected] 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.