4 ms·
Authentication with Warden (Rails)
- epochwolf 13y agoWow... 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 13y agoI 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 13y agoWhat benefit does Warden have over just rolling your own code?
- justinjlynn 13y agoIt 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 13y agoGranted, 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.
- jguimont 13y agoI 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.
- epochwolf 13y agoThis 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.
- byroot 13y agoThis implementation is vulnerable to timing attacks [0] [0] http://emerose.com/timing-attacks-explained http://emerose.com/timing-attacks-explained
- pothibo 13y agoAre 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 13y agoNo you're right my bad. I commented way too quickly.