Authentication with Warden (Rails) | Hacker News Reader

Authentication with Warden (Rails)

pothibo.com

18 pointspothibo10 comments

Wow... Let's take something simple and make it a pain in the ass.

No explaination of why one would use warden over a user_id in the session. I get devise, I use it myself. I don't understand using warden by itself. It looks like one of those tools best suited as an internal framework library.

You don't need warden's abstraction and obfuscation if you aren't building code that's shared with other applications.

I guess I should have explained myself better in the introduction.

The reason I am now using Warden over devise is that there's not a lot of code overhead to get to the functionality I needed.

The post is long, I agree, but the bottom line is what? 50 lines of codes more than you would need when you use devise?

Because frankly, I almost always use custom controller for sessions and registration, and if you style your forms, then you probably don't use the default forms provided with devise.

As for warden over user_id, well. I just showed a email/password strategy, but you can add strategy on top of each other, so if you use 1 strategy for your API another for the web interface and so on, warden can be useful.

I'm not preaching for 1 solution fit-all and I don't dislike devise, I just showed an alternative :)

What benefit does Warden have over just rolling your own code?

It is well tested and widely used. Thus, it is more likely to: be familiar to the average Joe developer you bring in off the market to work on your application, and it is also less likely to have a lot of the stupid security mistakes I see in custom rolled authentication code.

Granted, I haven't seen all rails application but I've never seen Warden used in the wild without Devise.

My issue is you are including warden when you could just write

    # ApplicationController
     
    def current_user
      if defined?(@current_user)
        @current_user 
      else
        @current_user = session[:user_id] && User.find_by_id(session[:user_id])
      end
    end
     
    def require_login
      redirect_to login_path unless current_user
    end
     
    # Session Controller
    def create
      if (@user = User.find_by_email(params[:email]) && @user.password == params[:password]
        session[:user_id] = @user.id
        redirect_to root_path, notice: "Logged in!"
      else
        render :new
      end
    end

Infact, all of this functionality is rewritten with far more code to make warden happy EXCEPT for `session[:user_id] = @user.id`. I don't see why I need to use warden for session management.

I think you should use warden if your rack application is composed of many applications. Never had to do this, so if someone wants to jump in, please do.

You can load different application within rack, for exemple, an api next to a web application. They can share the same user logins but they do not share any code. So you push the user login to the rack stack and let warden handle it.

This falls under the framework/shared code exception I mentioned. That's an excellent time to use some abstraction.

My concern is this looks like an unnecessary complication for a single rails application which is the most common use case for rails.

This implementation is vulnerable to timing attacks [0]

[0] http://emerose.com/timing-attacks-explained

Are you sure about that?

https://github.com/codahale/bcrypt-ruby/issues/42

I'm not refuting. I'm asking a question because it was discussed quite extensively here: https://github.com/codahale/bcrypt-ruby/pull/43

No you're right my bad. I commented way too quickly.

Reply on news.ycombinator.com