4 ms·
I've gone through 9 chapters of this tutorial, but I don't know if I want to finish it. The first few chapters were great and a lot of fun. Michael removed a lo
by elbenshira 16y ago
I've gone through 9 chapters of this tutorial, but I don't know if I want to finish it. The first few chapters were great and a lot of fun. Michael removed a lot of magic that I never understood. But I suppose my worries are irreconcilable: Michael attempts to please both programmers and non-programmers at the same time.
For example, I enjoyed things such as Figure 2.11 (a detailed explanation of MVC in Rails), but then Michael flashes through Ruby in Chapter 4. I understood it because I'm a programmer, but I don't know if any of the other target audiences would.
And as the tutorial progressed, I felt that Michael explained concepts and topics less and less.
For example, for user sign-in/out, another Rails book simply insert a session[:user_id] = @user.id, but Michael goes through the trouble of creating a new User.remeber_token field (Chapter 9). Why?
Security? Surely not, since he previously explained that cookies are checksumed to make sure that it was not tampered with on the client side. Efficiency? Nope. The session[:user_id] = @user.id is more efficient.
Then there are also other quirks such as modifying the Users table everytime the user logs in (it calls User.remember_me!). (I might be wrong about this, please check me).
I started this tutorial to remove some magic fairy dust from my eyes, but I'm afraid it has blinded me even more.
Michael, I'd really appreciate it if you could answer some of my questions.
NOTE: I've played around w/ RoR before, but not much.
- mhartl 16y agoI think that as the tutorial progresses, the number of potential confusions increases combinatorially. I've done my best to answer them in the text, but given the broad audience for the book it's hard to anticipate all possible questions. I'll do my best to answer your questions. The session[:user_id] solution you mention only persists over one session, i.e., if a user closes his browser, his session is lost. The tutorial's remember token, on the other hand, persists even after the browser is closed. Once you have a persistent cookie, though, you have a potential security breach. The reason a persistent cookie can't just be the user id is because it can be trivially spoofed: if you can simulate a cookie with id 17 (not hard with, e.g., Perl, Python, or Ruby), you can log in as user 17. That would be a Bad Thing™. By hashing the user id with a salt, we avoid this problem. I've made a note to motivate the remember token better in the tutorial. Saving the user on each login is correct; it's needed to change the remember token for security purposes. That the remember token doesn't currently change on each login is a bug in the tutorial, and I'll fix it ASAP (probably tomorrow). (The id-salt hash should also include a timestamp.) Finally, Rails does have a lot of magic, which is a source of its power but is also a potential stumbling block. The Rails Tutorial book is designed not to remove fairy dust but rather to teach you how to use it—mainly because most Rails application developers never need to know what's behind the curtain. (Indeed, in many cases I don't know, nor do I particularly care. After all, Ruby is mostly written in C, but you don't have to dig into the C source to use Ruby.) If you're a pull-back-the-curtain kind of guy, I recommend The Rails Way as a companion volume to Rails Tutorial. You've raised some good issues here. Let me know if you have any other suggestions: http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback
- deleted 16y ago[deleted]
- epochwolf 16y agoYou can configure cookie-based sessions to be persistent. http://api.rubyonrails.org/classes/ActionController/Session/CookieStore.html http://api.rubyonrails.org/classes/ActionController/Session/... For rails 3 in config/initializers/session_store.rb Rails.application.config.session_store :cookie_store, :key => '_session', :expire_after => 2.weeks
- mhartl 16y agoI'll take a look at this. I know that Rails 3 has a new way of doing things, but every Rails 2.3.x authentication system I've seen uses some kind of remember token. Maybe we're all just doing it wrong. :-) Update: I don't see any way to persist the session variable (where do the options go in session[:user_id] = user.id?), and I'm a little nervous about doing so, since the whole point of a session is that it doesn't persist. I'll stick with cookies for now. The Rails 3 version of the tutorial will probably use "permanent" cookies as per this blog post: http://m.onkey.org/2010/2/5/signed-and-permanent-cookies-in-rails-3 http://m.onkey.org/2010/2/5/signed-and-permanent-cookies-in-...
- epochwolf 16y agoWell I did roll my own signed cookies using http://gist.github.com/416030 http://gist.github.com/416030 Just a note, that cookie is used by created by rails and used dokuwiki using a custom authenication class I made. (dokuwiki verifies the signing)
- deleted 16y ago[deleted]
- elbenshira 16y agoThanks for the reply. I am now at peace and can continue the tutorial. But a question. I guess I don't fully comprehend Rails sessions, but if you try to spoof user 17, wouldn't Rails notice this due to the cookie checksum?
- mhartl 16y agoI've added a box in Chapter 9 addressing some of your concerns: http://www.railstutorial.org/chapters/sign-in-sign-out#sidebar:session_cookie http://www.railstutorial.org/chapters/sign-in-sign-out#sideb... Thanks again for bringing this to my attention! :-)
- mhartl 16y agoI've fixed the cookie/remember token issues in Chapter 9. See especially http://www.railstutorial.org/chapters/sign-in-sign-out#sidebar:session_cookie http://www.railstutorial.org/chapters/sign-in-sign-out#sideb... and the material surrounding http://www.railstutorial.org/chapters/sign-in-sign-out#code:remember_me http://www.railstutorial.org/chapters/sign-in-sign-out#code:...