This question aims to understand RoR and frameworks in general. It looks like RoR never had any standard user authentication system. Was it just historical reason (just happened naturally as it did)... or could it be intentional? Because RoR is a website building tool, more often than not, user authentication is a crucial part of a website.
To put it into perspective, another question is, do other popular frameworks, Django, Symfony, CakePHP, have user authentication built in?
There is no reasonably generic way to do user authentication. Most frameworks leave it up to you to choose the plugin that most closely matches what you're trying to accomplish.
For example, consider these two situations:
a blog which has a single administrator with password-protected admin-facing tools
a site like YouTube which allows users to sign up and administer their own content
Both of these sites would require vastly different authentication systems; which of these systems should Rails cater to out-of-the-box?
The Rails core team wanted to ensure that Rails was open-ended enough to make anything you want. There is no one-size-fits-all authentication scheme, so the core team decided to leave it out. Rails is easily extendable via gems and plugins, so that is where they belong.
Some examples are Warden and the Rails Warden plugin, Devise, Authlogic, and Restful Authentication.
CakePHP has a built in Authentication component that is pretty straight forward and easy to implement.
Most of these frameworks you mentioned are toolkits, not complete products. You build these things yourself, or leverage plugins from the community. Django's admin plugin/module has authentication out of the box though. Drupal does too, as a matter of fact.
Authentication can be(and is in my opinion) a matter of taste and need. If Rails was including things like that, it would start to become a website and not a framework. The programmer has to be free to choose among various implementations. That is why gems are available.
I've been programming a little in Rails and CakePHP, and I can say that Rails doesn't need to provide a mechanism like this. The community is very very good, and there are many examples (already said, like Devise, Authlogic...) made by very good programmers. Of course, there are many tutorials online (and also, railscasts, which are simply awesome) to program a succesful set-up for your project. So, if we have all of this, why should we need something like cakePHP mechanism? It's OK, it works, but there's just a very good tutorial and that's all( and maybe enough..). So, in the end, if u have a nice community you shouldn't care about the core of the technology, there will be always someone else more experienced with your needs that will do it for you. And if you don't find it, do it by yourself and in the proccess you will find a lot of help! :)
Related
As stated in the title, when should devise be used and when should I, instead, implement my own authentication. In essence, I'm wondering whether the created authentications in some tutorials (such as this one) are secure and safe.
If I don't need email confirmation, recoverability, etc. (a lot of the "jazz" associated with Devise), would the account information be just as secure as if I created my own?
If you still may be confused by what answer I'm looking for – is Devise something you should use whenever possible/whenever you have accounts? Or should it really be a decision?
Note: I'm not specifically referring to Devise, any authentication gems may be replaced.
implement my own authentication
Anytime you start thinking whether you should create your own authentication, you need to stop. Take that idea, shred it, douse it with gasoline, and burn it!
Authentication is hard. There are subtleties that exist in authentication and developers that are used to CRUD style programming are going to miss them. This isn't meant to be an insult. I am one of those programmers, and I work in security. Recognize your strengths and weaknesses.
Devise (and most popular authentication frameworks) have had thousands of hours of code review, design, testing, and time in production versus the framework that you're going to roll yourself.
I wrote a blog post about a "smart" security feature that actually made a company's security worse. This is a good example of how subtle authentication and security can be!
I used to use gems like Devise until Rails added the has_secure_password to ActiveRecord. Now I always roll my own since in the end I always need some custom stuff that makes it hard to implement in an existing library.
Ryan Bates have an excellent video on just this topic here.
In my opinion you should decide it according to your project. If you are working on small web-service with minimalistic functionality you can add your own auth using instruments provided by Rails. But if you are working on so-called "enterprise", big project with fast-growing functionality you should definitely use devise, since with this gem, you will not spend time on building existing auth features, it is very easy in maintenance and secure.
Some ruby gems like jekyll, toto and webby offer out of the box blog-type integration into your ruby app. Another way of developing a rich web blog-type application is to build and model the application yourself using pure ruby and rails practices. (e.g creating an Article and User model). The first offers out of the box features the 2nd option offers more customization and control.
In people's experience on Stack Overflow, which would be the best route and what would people consider when making the decision to use a gem out of the box versus going alone?
All of the gems you mentioned take static, markdown/textile/etc files and turn them into HTML websites. They take different approaches to it, with jekyll spitting out the finished website for hosting, toto doing the converting and routing on request, and webby doing the same as jekyll mostly.
If you're using Rails, it's important to note that none of these will integrate into your application well. They're built to more-or-less operate on their own.
Generally speaking, if a gem has the functionality you need, use it. They are not equivalent to plugins you find for Wordpress and Drupal where they are typically low-quality, buggy, poorly documented, etc. More often than not, gems simply add a couple modules that you can integrate into your application how you like.
On the other hand, a basic blog is pretty quick and simple in Rails, especially considering you've got a handy walkthrough guide straight from the Rails documentation on how to do it.
If you're new to Rails and want tight integration with your app, it's probably best to bake your own blog features.
This will take some time to do, but its worth it to learn how things really work.
If you're more seasoned, just look at the gem's API and documentation and decide if it does what you want it to do and if you're comfortable with how to integrate it. If so, it'll save you time.
One other consideration: who will be using the blog? Is it for internal use, and programmers will be the ones updating it? If that's the case, then you can make it very easy by not worrying about a lot of aesthetic polish in the back-end. Conversely, if you're making an app that includes a blogging component for the general public you might want it to feel more polished. In this case a gem might save you a lot of time.
It depends on your application.
It seems that a lot of Ruby on Rails questions are related to AuthLogic. What are the advantages of it that it is so popular?
It's popular because with Rails 2.2, it was the most complete authentication plugin system.
The authentication is often the base of each web application. It's quickly used on a lot of projects and often beginners start by blindly adding the authlogic plugin. The beginner doesn't understand how it's works, and ask some questions on SO.
There is a new, great, and complete plugin for Rails 2.2 and Rails 3. It's called devise. A lot of people come with questions about it as well.
Each plugin is good, each is different. You just need to choose what you want.
There are a few self-contained user frameworks, and AuthLogic is one of the earliest full-featured varieties. Thoughtbot is also pretty good at marketing their technology, and their other gem, Paperclip, is very popular as well.
The advantage of AuthLogic is that you can get slap on a user authentication system quite easily to an existing application without having to roll your own, something that is challenging for someone unfamiliar with Rails.
Because it works.
I'm looking to build an application that handles authentication and authorization for a variety of smaller apps that may or may not be rails applications (e.g. some with sinatra, some with non-ruby frameworks, etc). These applications will be on separate domains.
Can I do this with Authlogic? I do not want to setup a rails application for each application, just use a central authenticator. I'm sure as I start reading and working the answer would become evident, but I'm trying to avoid a dead end (doing work and research, then finding out this can't be done.)
From what I've read this is a use case, and I'm looking for input from people who've done similar. This is at the idea stage so if i can offer more detail, let me know.
I think you are planning to build a cross domain, single sign-on service. Besides building your own, there are a quite a few project that do this out of the box.
rubycas is one of them : http://code.google.com/p/rubycas-server/
You could also look into open Id (http://openid.net), where the login functionality is done by a third party authentication server.
In case you want to roll your own:
It doesn't really matter which authentication plugin/system you will use. (I would choose devise/warden, but Authlogic will do just fine). Instead you need to focus on understanding the security problems and the http interaction between your service, the browser and the application for which authentication is used. I think it's doable, but you need to know what you are doing.
Today, the cool kids use warden, or the railsy thingy devise.
Im not sure but i think you cant use authlogic with a non-ruby-app.
I would probably go with Devise as well but you should look into some plugins for it like JanRain's Engage (used to be RPX Now). It allows you to use quite a few social login options (Facebook, Twitter, etc.) http://www.janrain.com/products/engage.
Ryan Bates from Railscasts.com just posted an episode on Devise using Engage this morning. http://railscasts.com/episodes/233-engage-with-devise
There are some more episodes about Devise on Railscasts too. http://railscasts.com/episodes?search=devise
If I were you I wouldn't reinvent the wheel. I'd use a third party service to authenticate and just get on with the project. Social connectors such as Engage will provide this functionality for you without all the time and expertise.
Does anyone know of a good guide on building your own authentication system in ruby on rails?
I want to roll my own system to use with my community im building :)
Thanks!
I'd recommend starting with Warden - it'll handle the very basics of sessions for you, and give you a good foundation to build your logic on top of. The Rails Warden plugin is a rather small library that helps integrate it into Rails. Both of these projects are fairly mature and well-constructed yet still under active development - they're good choices all around.
You should be aware of Devise, another authentication framework (like Authlogic or Restful Authentication) that is based on Warden. It may not be a good fit for your project (it wasn't for mine), but looking through the source might give you a few ideas on how best to use Warden.
The other thing I'll note is that, in terms of hashing passwords, you should absolutely use bcrypt.
michael hartl has a good book coming out soon and the first 8 chapters are available in pdf format for free here: http://www.railstutorial.org/ - they cover the entire process of creating a very solid rspec-driven authentication system - can't recommend it highly enough
Well, it came out a while after you asked your question but the best answer if you're keen to build your own authentication system rather than use something like Devise would probably have to be Ryan Bates' Authentication from Scratch Screencast.
Since authentication is a common problem that has been solved many times already, I would start by investigating the solutions already out there.
For example, have a look at Restful Authentication which provides a good foundation for authentication in Rails. Even if you'd rather roll your own system, playing around with Restful Authentication and understanding how it works should give you a good understanding of the components needed when you start building your own system.
Check out this article:
http://www.aidanf.net/rails_user_authentication_tutorial
The author goes, step by step, through an entire authentication framework, with suggestions on further improvements. Even tests are discussed.
I agree with Ritchie... Devise has some very nice features but it doesn't play nice with others. For many use-cases, the way it hijacks the routing can make your job more difficult. In many situations you may be better off rolling your own.
Devise has caused circular references in my Rails asset pipeline, and the settings in the initializer as installed (in the latest version as of yesterday) conflicted with the defaults in the migration it generated.
I have built enterprise-level authentication systems, including email verification, password recovery, etc. And none of it required the routing shenanigans that Devise uses. If you really need all the features, it may be for you. But there are lots of reasons to not use it, too.