Chapter 7 ("Sign up") of the Ruby on Rails Tutorial book is out | Hacker News Reader

Chapter 7 ("Sign up") of the Ruby on Rails Tutorial book is out

railstutorial.org

29 pointsmhartl12 comments

Thanks Michael! My friend and I are just starting a website and we decided to do it using RoR even though our knowledge is close to none. We're both PHP developers and thought that if we made a website in RoR we would learn it by trial-and-error. I just heard about railstutorial.org today. I have skimmed through your tutorial book and find it quite useful. I will definitely read it in the next couple of days! (:

You're welcome! Be sure to send me feedback on anything you find confusing or if you find any errors. I should be able to fix them straightaway since my publication process goes something like this:

  $ <fix problem>
  $ git commit -am "Fixed problem"
  $ deploy tutorial

This generates the HTML and builds the PDF from the same source, and then pushes them both up to Heroku. It's very satisfying. :-)

For those of you clicking on this link who haven't yet looked at Michael's tutorial, it's excellent. I'm not a developer, know no languages other than a bit of html & css, and still had a fun time getting through chapters 1-4. Michael is a very good writer (check out RailsSpace) and has spent a lot of time thinking about the best way to teach.

RailsTutorial, like Ruby and Rails, just feels right.

-- Fred

Michael, thanks! Awesome work.

If I might suggest one improvement: I'd change @title with content_for. A class attribute needlessly messes View and Controller.

That's a good suggestion, and I'll definitely think about it. Early on in the tutorial I'd prefer to keep it as-is for simplicity and to help motivate instance variables. Also, it seems that setting instance variables in controllers for use in views is a common pattern. But switching to content_for at some point might make for a nice example of refactoring. (Good thing the book has tests for page titles. ;-)

EDIT: Come to think of it, this might make for a good exercise.

  def create
    @user = User.new(params[:user])
    @title = "Sign up"
    render 'new'
  end

So the end user can mess around with the form, add is_admin=1 to the other CGI params and end up with an admin account. (Or similar.) Fabulous.

No. Read this: http://www.railstutorial.org/chapters/modeling-and-viewing-u...

I don't see a problem with distilling an example to the basics when teaching beginners. Your concern should certainly be addressed at some point in the book though.

Indeed. See my other comment. :-)

Prolly should have read the rest of the book first, as shown in the link before, this isn't an issue

You raise an important issue, which I've written about before (http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-a... and http://blog.mhartl.com/2008/09/21/finding-and-fixing-mass-as...) and emphasize in the Ruby on Rails Tutorial book. Happily, in this case there is no cause for concern.

(1) The book uses test-driven development for the most part; the snippet you pasted is just enough to get the "failed signup" test to pass, and is not the full implementation. (2) The code you copied doesn't even save the user, so there's no potential security breach at this point. (3) There's no admin attribute yet. (It's coming in Chapter 9.) (4) The User model is protected by attr_accessible in any case, as discussed in Chapter 5 (http://www.railstutorial.org/chapters/modeling-and-viewing-u...). There's no way to tell from inspecting a controller action whether or not there's a security breach at the model level.

N.B. Just yesterday I exchanged notes with Yehuda Katz on this very subject; he and Carl Lerche both agree that Rails should close the attr_accessible security hole by default, much as Rails 3 now escapes the output of Embedded Ruby by default. My hope is that we'll see this implemented in Rails 3.x, for some value of x.

attr_accessible, messieur

Reply on news.ycombinator.com