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