

Authentication with Warden (Rails) - pothibo
http://pothibo.com/2013/07/authentication-with-warden-devise-less/

======
epochwolf
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.

~~~
pothibo
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 :)

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

~~~
justinjlynn
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.

~~~
epochwolf
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.

------
byroot
This implementation is vulnerable to timing attacks [0]

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

~~~
pothibo
Are you sure about that?

[https://github.com/codahale/bcrypt-
ruby/issues/42](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](https://github.com/codahale/bcrypt-ruby/pull/43)

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

