From 4760464efb94297d14d6a35a53da0459ee4d7d7e Mon Sep 17 00:00:00 2001 From: Vijay Dev Date: Sun, 1 May 2011 15:46:46 +0530 Subject: fix GitHub guides url --- railties/guides/source/contributing_to_ruby_on_rails.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'railties/guides') diff --git a/railties/guides/source/contributing_to_ruby_on_rails.textile b/railties/guides/source/contributing_to_ruby_on_rails.textile index d7090ef675..61a17b6a56 100644 --- a/railties/guides/source/contributing_to_ruby_on_rails.textile +++ b/railties/guides/source/contributing_to_ruby_on_rails.textile @@ -44,7 +44,7 @@ Ruby on Rails uses git for source code control. The "git homepage":http://git-sc * "Everyday Git":http://www.kernel.org/pub/software/scm/git/docs/everyday.html will teach you just enough about git to get by. * The "PeepCode screencast":https://peepcode.com/products/git on git ($9) is easier to follow. -* "GitHub":https://github.com/guides/home offers links to a variety of git resources. +* "GitHub":http://help.github.com offers links to a variety of git resources. * "Pro Git":http://progit.org/book/ is an entire book about git with a Creative Commons license. h4. Clone the Ruby on Rails Repository @@ -232,7 +232,7 @@ You can also help out by examining pull requests that have been submitted to Rub $ git checkout -b testing_branch -Then you can use their remote branch to update your codebase. For example, let's say the github user JohnSmith has forked and pushed to the master branch located at http://github.com/JohnSmith/rails. +Then you can use their remote branch to update your codebase. For example, let's say the GitHub user JohnSmith has forked and pushed to the master branch located at https://github.com/JohnSmith/rails. $ git remote add JohnSmith git://github.com/JohnSmith/rails.git -- cgit v1.2.3 From d1f765644891d6cf6555003de52cb6d58a4da33b Mon Sep 17 00:00:00 2001 From: Vijay Dev Date: Sun, 1 May 2011 16:15:53 +0530 Subject: remove info about adding verified tag --- railties/guides/source/contributing_to_ruby_on_rails.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'railties/guides') diff --git a/railties/guides/source/contributing_to_ruby_on_rails.textile b/railties/guides/source/contributing_to_ruby_on_rails.textile index 61a17b6a56..a7d792f88d 100644 --- a/railties/guides/source/contributing_to_ruby_on_rails.textile +++ b/railties/guides/source/contributing_to_ruby_on_rails.textile @@ -252,7 +252,7 @@ Once you're happy that the pull request contains a good change, comment on the G I like the way you've restructured that code in generate_finder_sql, much nicer. The tests look good too. -If your comment simply says "+1", then odds are that other reviewers aren't going to take it too seriously. Show that you took the time to review the patch. Once three people have approved it, add the "verified" tag. This will bring it to the attention of a core team member who will review the changes looking for the same kinds of things. +If your comment simply says "+1", then odds are that other reviewers aren't going to take it too seriously. h3. Contributing to the Rails Documentation -- cgit v1.2.3 From ca608b8c9c9bc47160f0413ce02d3315f89ef537 Mon Sep 17 00:00:00 2001 From: Sebastian Martinez Date: Sun, 1 May 2011 12:28:16 -0300 Subject: Bring this back on the contributing guide. --- railties/guides/source/contributing_to_ruby_on_rails.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'railties/guides') diff --git a/railties/guides/source/contributing_to_ruby_on_rails.textile b/railties/guides/source/contributing_to_ruby_on_rails.textile index a7d792f88d..cb09b180a2 100644 --- a/railties/guides/source/contributing_to_ruby_on_rails.textile +++ b/railties/guides/source/contributing_to_ruby_on_rails.textile @@ -252,7 +252,7 @@ Once you're happy that the pull request contains a good change, comment on the G I like the way you've restructured that code in generate_finder_sql, much nicer. The tests look good too. -If your comment simply says "+1", then odds are that other reviewers aren't going to take it too seriously. +If your comment simply says "+1", then odds are that other reviewers aren't going to take it too seriously. Show that you took the time to review the pull request. h3. Contributing to the Rails Documentation -- cgit v1.2.3 From 9fa080e703362876b5afe9a7627bf3ffb6fa131e Mon Sep 17 00:00:00 2001 From: Sebastian Martinez Date: Mon, 2 May 2011 00:15:36 -0300 Subject: Update security guide with #new and #create respect mass-assignment --- railties/guides/source/security.textile | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) (limited to 'railties/guides') diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile index f87ffdb20d..40fe764ae9 100644 --- a/railties/guides/source/security.textile +++ b/railties/guides/source/security.textile @@ -441,7 +441,7 @@ params[:user] # => {:name => "ow3ned", :admin => true} @user.admin # => true -When assigning attributes in Active Record using +new+, +attributes=+, or +update_attributes+ the :default scope will be used. To assign attributes using different scopes you should use +assign_attributes+ which accepts an optional :as options parameter. If no :as option is provided then the :default scope will be used. You can also bypass mass-assignment security by using the +:without_protection+ option. Here is an example: +When assigning attributes in Active Record using +attributes=+, or +update_attributes+ the :default scope will be used. To assign attributes using different scopes you should use +assign_attributes+ which accepts an optional :as options parameter. If no :as option is provided then the :default scope will be used. You can also bypass mass-assignment security by using the +:without_protection+ option. Here is an example: @user = User.new @@ -459,7 +459,19 @@ When assigning attributes in Active Record using +new+, +attributes=+, or +updat @user.is_admin # => true -A more paranoid technique to protect your whole project would be to enforce that all models define their accessible attributes. This can be easily achieved with a very simple application config option of: +In a similar way, +new+, +create+ and create! methods respect mass-assignment security and accepts either +:as+ or +:without_protection+ options. For example: + + +@user = User.new({ :name => 'Sebastian', :is_admin => true }, :as => :admin) +@user.name # => Sebastian +@user.is_admin # => true + +@user = User.create({ :name => 'Sebastian', :is_admin => true }, :without_protection => true) +@user.name # => Sebastian +@user.is_admin # => true + + +A more paranoid technique to protect your whole project would be to enforce that all models define their accessible attributes. This can be easily achieved with a very simple application config option of: config.active_record.whitelist_attributes = true -- cgit v1.2.3 From 527036ebd106fdb4d5890f00f2576a99c57b1514 Mon Sep 17 00:00:00 2001 From: Vijay Dev Date: Mon, 2 May 2011 17:31:00 +0530 Subject: removed verify docs (feature removed in Rails3) --- .../source/action_controller_overview.textile | 39 ---------------------- 1 file changed, 39 deletions(-) (limited to 'railties/guides') diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile index f8b586c151..3a1a4ee66e 100644 --- a/railties/guides/source/action_controller_overview.textile +++ b/railties/guides/source/action_controller_overview.textile @@ -488,45 +488,6 @@ end Again, this is not an ideal example for this filter, because it's not run in the scope of the controller but gets the controller passed as an argument. The filter class has a class method +filter+ which gets run before or after the action, depending on if it's a before or after filter. Classes used as around filters can also use the same +filter+ method, which will get run in the same way. The method must +yield+ to execute the action. Alternatively, it can have both a +before+ and an +after+ method that are run before and after the action. -h3. Verification - -Verifications make sure certain criteria are met in order for a controller or action to run. They can specify that a certain key (or several keys in the form of an array) is present in the +params+, +session+ or +flash+ hashes or that a certain HTTP method was used or that the request was made using +XMLHttpRequest+ (Ajax). The default action taken when these criteria are not met is to render a 400 Bad Request response, but you can customize this by specifying a redirect URL or rendering something else and you can also add flash messages and HTTP headers to the response. - -Here's an example of using verification to make sure the user supplies a username and a password in order to log in: - - -class LoginsController < ApplicationController - verify :params => [:username, :password], - :render => {:action => "new"}, - :add_flash => { - :error => "Username and password required to log in" - } - - def create - @user = User.authenticate(params[:username], params[:password]) - if @user - flash[:notice] = "You're logged in" - redirect_to root_url - else - render :action => "new" - end - end -end - - -Now the +create+ action won't run unless the "username" and "password" parameters are present, and if they're not, an error message will be added to the flash and the +new+ action will be rendered. But there's something rather important missing from the verification above: It will be used for *every* action in LoginsController, which is not what we want. You can limit which actions it will be used for with the +:only+ and +:except+ options just like a filter: - - -class LoginsController < ApplicationController - verify :params => [:username, :password], - :render => {:action => "new"}, - :add_flash => { - :error => "Username and password required to log in" - }, - :only => :create # Run only for the "create" action -end - - h3. Request Forgery Protection Cross-site request forgery is a type of attack in which a site tricks a user into making requests on another site, possibly adding, modifying or deleting data on that site without the user's knowledge or permission. -- cgit v1.2.3 From 09edaf49646c14b6162726c1fb2bc0e980c3962f Mon Sep 17 00:00:00 2001 From: Vijay Dev Date: Mon, 2 May 2011 17:39:46 +0530 Subject: removed reference to verify method --- railties/guides/source/security.textile | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) (limited to 'railties/guides') diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile index 40fe764ae9..8c408ec06b 100644 --- a/railties/guides/source/security.textile +++ b/railties/guides/source/security.textile @@ -211,15 +211,7 @@ The HTTP protocol basically provides two main types of requests - GET and POST ( If your web application is RESTful, you might be used to additional HTTP verbs, such as PUT or DELETE. Most of today‘s web browsers, however do not support them - only GET and POST. Rails uses a hidden +_method+ field to handle this barrier. -_(highlight)The verify method in a controller can make sure that specific actions may not be used over GET_. Here is an example to verify the use of the transfer action over POST. If the action comes in using any other verb, it redirects to the list action. - - -verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list} - - -With this precaution, the attack from above will not work, because the browser sends a GET request for images, which will not be accepted by the web application. - -But this was only the first step, because _(highlight)POST requests can be sent automatically, too_. Here is an example for a link which displays www.harmless.com as destination in the browser's status bar. In fact it dynamically creates a new form that sends a POST request. +_(highlight)POST requests can be sent automatically, too_. Here is an example for a link which displays www.harmless.com as destination in the browser's status bar. In fact it dynamically creates a new form that sends a POST request.