diff options
Diffstat (limited to 'guides')
| -rw-r--r-- | guides/rails_guides/generator.rb | 2 | ||||
| -rw-r--r-- | guides/source/_welcome.html.erb | 2 | ||||
| -rw-r--r-- | guides/source/action_controller_overview.md | 47 | ||||
| -rw-r--r-- | guides/source/action_mailer_basics.md | 8 | ||||
| -rw-r--r-- | guides/source/action_view_overview.md | 2 | ||||
| -rw-r--r-- | guides/source/active_model_basics.md | 88 | ||||
| -rw-r--r-- | guides/source/active_record_basics.md | 42 | ||||
| -rw-r--r-- | guides/source/active_record_callbacks.md | 2 | ||||
| -rw-r--r-- | guides/source/active_record_querying.md | 14 | ||||
| -rw-r--r-- | guides/source/active_record_validations.md | 42 | ||||
| -rw-r--r-- | guides/source/caching_with_rails.md | 2 | ||||
| -rw-r--r-- | guides/source/i18n.md | 8 | ||||
| -rw-r--r-- | guides/source/security.md | 2 |
13 files changed, 145 insertions, 116 deletions
diff --git a/guides/rails_guides/generator.rb b/guides/rails_guides/generator.rb index 3b124ef236..a53d34a279 100644 --- a/guides/rails_guides/generator.rb +++ b/guides/rails_guides/generator.rb @@ -84,7 +84,7 @@ module RailsGuides @warnings = ENV['WARNINGS'] == '1' @all = ENV['ALL'] == '1' @kindle = ENV['KINDLE'] == '1' - @version = ENV['RAILS_VERSION'] || `git rev-parse --short HEAD`.chomp + @version = ENV['RAILS_VERSION'] || 'local' @lang = ENV['GUIDES_LANGUAGE'] end diff --git a/guides/source/_welcome.html.erb b/guides/source/_welcome.html.erb index 9d2e9c1d68..a50961a0c7 100644 --- a/guides/source/_welcome.html.erb +++ b/guides/source/_welcome.html.erb @@ -1,4 +1,4 @@ -<h2>Ruby on Rails Guides (<%= @version %>)</h2> +<h2>Ruby on Rails Guides (<%= @edge ? @version[0, 7] : @version %>)</h2> <% if @edge %> <p> diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md index f17f850107..46ff9027fd 100644 --- a/guides/source/action_controller_overview.md +++ b/guides/source/action_controller_overview.md @@ -434,7 +434,7 @@ Filters are inherited, so if you set a filter on `ApplicationController`, it wil ```ruby class ApplicationController < ActionController::Base - before_filter :require_login + before_action :require_login private @@ -458,11 +458,11 @@ end The method simply stores an error message in the flash and redirects to the login form if the user is not logged in. If a "before" filter renders or redirects, the action will not run. If there are additional filters scheduled to run after that filter, they are also cancelled. -In this example the filter is added to `ApplicationController` and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_filter`: +In this example the filter is added to `ApplicationController` and thus all controllers in the application inherit it. This will make everything in the application require the user to be logged in in order to use it. For obvious reasons (the user wouldn't be able to log in in the first place!), not all controllers or actions should require this. You can prevent this filter from running before particular actions with `skip_before_action`: ```ruby class LoginsController < ApplicationController - skip_before_filter :require_login, only: [:new, :create] + skip_before_action :require_login, only: [:new, :create] end ``` @@ -480,7 +480,7 @@ For example, in a website where changes have an approval workflow an administrat ```ruby class ChangesController < ActionController::Base - around_filter :wrap_in_transaction, only: :show + around_action :wrap_in_transaction, only: :show private @@ -502,13 +502,13 @@ You can choose not to yield and build the response yourself, in which case the a ### Other Ways to Use Filters -While the most common way to use filters is by creating private methods and using *_filter to add them, there are two other ways to do the same thing. +While the most common way to use filters is by creating private methods and using *_action to add them, there are two other ways to do the same thing. -The first is to use a block directly with the *_filter methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block: +The first is to use a block directly with the *_action methods. The block receives the controller as an argument, and the `require_login` filter from above could be rewritten to use a block: ```ruby class ApplicationController < ActionController::Base - before_filter do |controller| + before_action do |controller| redirect_to new_login_url unless controller.send(:logged_in?) end end @@ -520,7 +520,7 @@ The second way is to use a class (actually, any object that responds to the righ ```ruby class ApplicationController < ActionController::Base - before_filter LoginFilter + before_action LoginFilter end class LoginFilter @@ -648,7 +648,7 @@ HTTP digest authentication is superior to the basic authentication as it does no class AdminController < ApplicationController USERS = { "lifo" => "world" } - before_filter :authenticate + before_action :authenticate private @@ -751,15 +751,36 @@ Now the user can request to get a PDF version of a client just by adding ".pdf" GET /clients/1.pdf ``` -Parameter Filtering -------------------- +Log Filtering +------------- + +Rails keeps a log file for each environment in the `log` folder. These are extremely useful when debugging what's actually going on in your application, but in a live application you may not want every bit of information to be stored in the log file. -Rails keeps a log file for each environment in the `log` folder. These are extremely useful when debugging what's actually going on in your application, but in a live application you may not want every bit of information to be stored in the log file. You can filter certain request parameters from your log files by appending them to `config.filter_parameters` in the application configuration. These parameters will be marked [FILTERED] in the log. +### Parameters Filtering + +You can filter certain request parameters from your log files by appending them to `config.filter_parameters` in the application configuration. These parameters will be marked [FILTERED] in the log. ```ruby config.filter_parameters << :password ``` +### Redirects Filtering + +Sometimes it's desirable to filter out from log files some sensible locations your application is redirecting to. +You can do that by using the `config.filter_redirect` configuration option: + +```ruby +config.filter_redirect << 's3.amazonaws.com' +``` + +You can set it to a String, a Regexp, or an array of both. + +```ruby +config.filter_redirect.concat ['s3.amazonaws.com', /private_path/] +``` + +Matching URLs will be marked as '[FILTERED]'. + Rescue ------ @@ -807,7 +828,7 @@ end class ClientsController < ApplicationController # Check that the user has the right authorization to access clients. - before_filter :check_authorization + before_action :check_authorization # Note how the actions don't have to worry about all the auth stuff. def edit diff --git a/guides/source/action_mailer_basics.md b/guides/source/action_mailer_basics.md index b2ccc2d82c..aaf04f4256 100644 --- a/guides/source/action_mailer_basics.md +++ b/guides/source/action_mailer_basics.md @@ -447,17 +447,17 @@ end Action Mailer Callbacks --------------------------- -Action Mailer allows for you to specify a `before_filter`, `after_filter` and 'around_filter'. +Action Mailer allows for you to specify a `before_action`, `after_action` and 'around_action'. * Filters can be specified with a block or a symbol to a method in the mailer class similar to controllers. -* You could use a `before_filter` to prepopulate the mail object with defaults, delivery_method_options or insert default headers and attachments. +* You could use a `before_action` to prepopulate the mail object with defaults, delivery_method_options or insert default headers and attachments. -* You could use an `after_filter` to do similar setup as a `before_filter` but using instance variables set in your mailer action. +* You could use an `after_action` to do similar setup as a `before_action` but using instance variables set in your mailer action. ```ruby class UserMailer < ActionMailer::Base - after_filter :set_delivery_options, :prevent_delivery_to_guests, :set_business_headers + after_action :set_delivery_options, :prevent_delivery_to_guests, :set_business_headers def feedback_message(business, user) @business = business diff --git a/guides/source/action_view_overview.md b/guides/source/action_view_overview.md index 4ea60391ba..6c2871d478 100644 --- a/guides/source/action_view_overview.md +++ b/guides/source/action_view_overview.md @@ -1484,7 +1484,7 @@ You can use the same technique to localize the rescue files in your public direc Since Rails doesn't restrict the symbols that you use to set I18n.locale, you can leverage this system to display different content depending on anything you like. For example, suppose you have some "expert" users that should see different pages from "normal" users. You could add the following to `app/controllers/application.rb`: ```ruby -before_filter :set_expert_locale +before_action :set_expert_locale def set_expert_locale I18n.locale = :expert if current_user.expert? diff --git a/guides/source/active_model_basics.md b/guides/source/active_model_basics.md index 0c278095ab..68ac26c681 100644 --- a/guides/source/active_model_basics.md +++ b/guides/source/active_model_basics.md @@ -10,7 +10,7 @@ After reading this guide, you will know: Introduction ------------ -Active Model is a library containing various modules used in developing frameworks that need to interact with the Rails Action Pack library. Active Model provides a known set of interfaces for usage in classes. Some of modules are explained below. +Active Model is a library containing various modules used in developing frameworks that need to interact with the Rails Action Pack library. Active Model provides a known set of interfaces for usage in classes. Some of modules are explained below. ### AttributeMethods @@ -26,23 +26,21 @@ class Person attr_accessor :age -private - def reset_attribute(attribute) - send("#{attribute}=", 0) - end + private + def reset_attribute(attribute) + send("#{attribute}=", 0) + end - def attribute_highest?(attribute) - send(attribute) > 100 ? true : false - end - + def attribute_highest?(attribute) + send(attribute) > 100 + end end person = Person.new person.age = 110 person.age_highest? # true person.reset_age # 0 -person.age_highest? # false - +person.age_highest? # false ``` ### Callbacks @@ -87,14 +85,14 @@ class Person end person = Person.new -person.to_model == person #=> true -person.to_key #=> nil -person.to_param #=> nil +person.to_model == person # => true +person.to_key # => nil +person.to_param # => nil ``` ### Dirty -An object becomes dirty when it has gone through one or more changes to its attributes and has not been saved. This gives the ability to check whether an object has been changed or not. It also has attribute based accessor methods. Let's consider a Person class with attributes first_name and last_name +An object becomes dirty when it has gone through one or more changes to its attributes and has not been saved. This gives the ability to check whether an object has been changed or not. It also has attribute based accessor methods. Let's consider a Person class with attributes `first_name` and `last_name`: ```ruby require 'active_model' @@ -123,8 +121,8 @@ class Person def save @previously_changed = changes + # do save work... end - end ``` @@ -132,21 +130,22 @@ end ```ruby person = Person.new -person.first_name = "First Name" +person.changed? # => false -person.first_name #=> "First Name" -person.first_name = "First Name Changed" +person.first_name = "First Name" +person.first_name # => "First Name" -person.changed? #=> true +# returns if any attribute has changed. +person.changed? # => true -#returns an list of fields arry which all has been changed before saved. -person.changed #=> ["first_name"] +# returns a list of attributes that have changed before saving. +person.changed # => ["first_name"] -#returns a hash of the fields that have changed with their original values. -person.changed_attributes #=> {"first_name" => "First Name Changed"} +# returns a hash of the attributes that have changed with their original values. +person.changed_attributes # => {"first_name"=>nil} -#returns a hash of changes, with the attribute names as the keys, and the values will be an array of the old and new value for that field. -person.changes #=> {"first_name" => ["First Name","First Name Changed"]} +# returns a hash of changes, with the attribute names as the keys, and the values will be an array of the old and new value for that field. +person.changes # => {"first_name"=>[nil, "First Name"]} ``` #### Attribute based accessor methods @@ -154,28 +153,24 @@ person.changes #=> {"first_name" => ["First Name","First Name Changed"]} Track whether the particular attribute has been changed or not. ```ruby -#attr_name_changed? -person.first_name #=> "First Name" - -#assign some other value to first_name attribute -person.first_name = "First Name 1" - -person.first_name_changed? #=> true +# attr_name_changed? +person.first_name # => "First Name" +person.first_name_changed? # => true ``` Track what was the previous value of the attribute. ```ruby -#attr_name_was accessor -person.first_name_was #=> "First Name" +# attr_name_was accessor +person.first_name_was # => "First Name" ``` Track both previous and current value of the changed attribute. Returns an array if changed, else returns nil. ```ruby -#attr_name_change -person.first_name_change #=> ["First Name", "First Name 1"] -person.last_name_change #=> nil +# attr_name_change +person.first_name_change # => [nil, "First Name"] +person.last_name_change # => nil ``` ### Validations @@ -187,20 +182,19 @@ class Person include ActiveModel::Validations attr_accessor :name, :email, :token - + validates :name, presence: true - validates_format_of :email, with: /\A([^\s]+)((?:[-a-z0-9]\.)[a-z]{2,})\z/i + validates_format_of :email, with: /\A([^\s]+)((?:[-a-z0-9]\.)[a-z]{2,})\z/i validates! :token, presence: true - end person = Person.new(token: "2b1f325") -person.valid? #=> false -person.name = 'vishnu' -person.email = 'me' -person.valid? #=> false +person.valid? # => false +person.name = 'vishnu' +person.email = 'me' +person.valid? # => false person.email = 'me@vishnuatrai.com' -person.valid? #=> true +person.valid? # => true person.token = nil -person.valid? #=> raises ActiveModel::StrictValidationFailed +person.valid? # => raises ActiveModel::StrictValidationFailed ``` diff --git a/guides/source/active_record_basics.md b/guides/source/active_record_basics.md index cb64cf39f3..68c6416e89 100644 --- a/guides/source/active_record_basics.md +++ b/guides/source/active_record_basics.md @@ -147,15 +147,15 @@ Active Record objects can be created from a hash, a block or have their attribut For example, given a model `User` with attributes of `name` and `occupation`, the `create` method call will create and save a new record into the database: ```ruby - user = User.create(name: "David", occupation: "Code Artist") +user = User.create(name: "David", occupation: "Code Artist") ``` Using the `new` method, an object can be created without being saved: ```ruby - user = User.new - user.name = "David" - user.occupation = "Code Artist" +user = User.new +user.name = "David" +user.occupation = "Code Artist" ``` A call to `user.save` will commit the record to the database. @@ -163,10 +163,10 @@ A call to `user.save` will commit the record to the database. Finally, if a block is provided, both `create` and `new` will yield the new object to that block for initialization: ```ruby - user = User.new do |u| - u.name = "David" - u.occupation = "Code Artist" - end +user = User.new do |u| + u.name = "David" + u.occupation = "Code Artist" +end ``` ### Read @@ -174,23 +174,23 @@ Finally, if a block is provided, both `create` and `new` will yield the new obje Active Record provides a rich API for accessing data within a database. Below are a few examples of different data access methods provided by Active Record. ```ruby - # return array with all records - users = User.all +# return array with all records +users = User.all ``` ```ruby - # return the first record - user = User.first +# return the first record +user = User.first ``` ```ruby - # return the first user named David - david = User.find_by_name('David') +# return the first user named David +david = User.find_by_name('David') ``` ```ruby - # find all users named David who are Code Artists and sort by created_at in reverse chronological order - users = User.where(name: 'David', occupation: 'Code Artist').order('created_at DESC') +# find all users named David who are Code Artists and sort by created_at in reverse chronological order +users = User.where(name: 'David', occupation: 'Code Artist').order('created_at DESC') ``` You can learn more about querying an Active Record model in the [Active Record Query Interface](active_record_querying.html) guide. @@ -200,9 +200,9 @@ You can learn more about querying an Active Record model in the [Active Record Q Once an Active Record object has been retrieved, its attributes can be modified and it can be saved to the database. ```ruby - user = User.find_by_name('David') - user.name = 'Dave' - user.save +user = User.find_by_name('David') +user.name = 'Dave' +user.save ``` ### Delete @@ -210,8 +210,8 @@ Once an Active Record object has been retrieved, its attributes can be modified Likewise, once retrieved an Active Record object can be destroyed which removes it from the database. ```ruby - user = User.find_by_name('David') - user.destroy +user = User.find_by_name('David') +user.destroy ``` Validations diff --git a/guides/source/active_record_callbacks.md b/guides/source/active_record_callbacks.md index 550800861d..971c1cdb25 100644 --- a/guides/source/active_record_callbacks.md +++ b/guides/source/active_record_callbacks.md @@ -200,7 +200,7 @@ Halting Execution As you start registering new callbacks for your models, they will be queued for execution. This queue will include all your model's validations, the registered callbacks, and the database operation to be executed. -The whole callback chain is wrapped in a transaction. If any <em>before</em> callback method returns exactly `false` or raises an exception, the execution chain gets halted and a ROLLBACK is issued; <em>after</em> callbacks can only accomplish that by raising an exception. +The whole callback chain is wrapped in a transaction. If any _before_ callback method returns exactly `false` or raises an exception, the execution chain gets halted and a ROLLBACK is issued; _after_ callbacks can only accomplish that by raising an exception. WARNING. Raising an arbitrary exception may break code that expects `save` and its friends not to fail like that. The `ActiveRecord::Rollback` exception is thought precisely to tell Active Record a rollback is going on. That one is internally captured but not reraised. diff --git a/guides/source/active_record_querying.md b/guides/source/active_record_querying.md index 889e869a2a..24f98f68ca 100644 --- a/guides/source/active_record_querying.md +++ b/guides/source/active_record_querying.md @@ -505,6 +505,20 @@ This code will generate SQL like this: SELECT * FROM clients WHERE (clients.orders_count IN (1,3,5)) ``` +### NOT, LIKE, and NOT LIKE Conditions + +`NOT`, `LIKE`, and `NOT LIKE` SQL queries can be built by `where.not`, `where.like`, and `where.not_like` respectively. + +```ruby +Post.where.not(author: author) + +Author.where.like(name: 'Nari%') + +Developer.where.not_like(name: 'Tenderl%') +``` + +In other words, these sort of queries can be generated by calling `where` with no argument, then immediately chain with `not`, `like`, or `not_like` passing `where` conditions. + Ordering -------- diff --git a/guides/source/active_record_validations.md b/guides/source/active_record_validations.md index 6e20e74c34..2e2f0e4ea9 100644 --- a/guides/source/active_record_validations.md +++ b/guides/source/active_record_validations.md @@ -264,7 +264,7 @@ class Person < ActiveRecord::Base end ``` -The default error message for this helper is "_must be accepted_". +The default error message for this helper is _"must be accepted"_. It can receive an `:accept` option, which determines the value that will be considered acceptance. It defaults to "1" and can be easily changed. @@ -293,7 +293,7 @@ This validation will work with all of the association types. CAUTION: Don't use `validates_associated` on both ends of your associations. They would call each other in an infinite loop. -The default error message for `validates_associated` is "_is invalid_". Note +The default error message for `validates_associated` is _"is invalid"_. Note that each associated object will contain its own `errors` collection; errors do not bubble up to the calling model. @@ -328,7 +328,7 @@ class Person < ActiveRecord::Base end ``` -The default error message for this helper is "_doesn't match confirmation_". +The default error message for this helper is _"doesn't match confirmation"_. ### `exclusion` @@ -348,7 +348,7 @@ alias called `:within` that you can use for the same purpose, if you'd like to. This example uses the `:message` option to show how you can include the attribute's value. -The default error message is "_is reserved_". +The default error message is _"is reserved"_. ### `format` @@ -362,7 +362,7 @@ class Product < ActiveRecord::Base end ``` -The default error message is "_is invalid_". +The default error message is _"is invalid"_. ### `inclusion` @@ -381,7 +381,7 @@ will be accepted. The `:in` option has an alias called `:within` that you can use for the same purpose, if you'd like to. The previous example uses the `:message` option to show how you can include the attribute's value. -The default error message for this helper is "_is not included in the list_". +The default error message for this helper is _"is not included in the list"_. ### `length` @@ -471,24 +471,24 @@ Besides `:only_integer`, this helper also accepts the following options to add constraints to acceptable values: * `:greater_than` - Specifies the value must be greater than the supplied - value. The default error message for this option is "_must be greater than - %{count}_". + value. The default error message for this option is _"must be greater than + %{count}"_. * `:greater_than_or_equal_to` - Specifies the value must be greater than or equal to the supplied value. The default error message for this option is - "_must be greater than or equal to %{count}_". + _"must be greater than or equal to %{count}"_. * `:equal_to` - Specifies the value must be equal to the supplied value. The - default error message for this option is "_must be equal to %{count}_". + default error message for this option is _"must be equal to %{count}"_. * `:less_than` - Specifies the value must be less than the supplied value. The - default error message for this option is "_must be less than %{count}_". + default error message for this option is _"must be less than %{count}"_. * `:less_than_or_equal_to` - Specifies the value must be less than or equal the - supplied value. The default error message for this option is "_must be less - than or equal to %{count}_". + supplied value. The default error message for this option is _"must be less + than or equal to %{count}"_. * `:odd` - Specifies the value must be an odd number if set to true. The - default error message for this option is "_must be odd_". + default error message for this option is _"must be odd"_. * `:even` - Specifies the value must be an even number if set to true. The - default error message for this option is "_must be even_". + default error message for this option is _"must be even"_. -The default error message is "_is not a number_". +The default error message is _"is not a number"_. ### `presence` @@ -528,7 +528,7 @@ If you validate the presence of an object associated via a `has_one` or Since `false.blank?` is true, if you want to validate the presence of a boolean field you should use `validates :field_name, inclusion: { in: [true, false] }`. -The default error message is "_can't be empty_". +The default error message is _"can't be empty"_. ### `uniqueness` @@ -570,7 +570,7 @@ end WARNING. Note that some databases are configured to perform case-insensitive searches anyway. -The default error message is "_has already been taken_". +The default error message is _"has already been taken"_. ### `validates_with` @@ -714,7 +714,7 @@ class Person < ActiveRecord::Base validates :name, presence: { strict: true } end -Person.new.valid? #=> ActiveModel::StrictValidationFailed: Name can't be blank +Person.new.valid? # => ActiveModel::StrictValidationFailed: Name can't be blank ``` There is also an ability to pass custom exception to `:strict` option @@ -724,7 +724,7 @@ class Person < ActiveRecord::Base validates :token, presence: true, uniqueness: true, strict: TokenGenerationException end -Person.new.valid? #=> TokenGenerationException: Token can't be blank +Person.new.valid? # => TokenGenerationException: Token can't be blank ``` Conditional Validation @@ -917,7 +917,7 @@ validations fail. Because every application handles this kind of thing differently, Rails does not include any view helpers to help you generate these messages directly. -However, due to the rich number of methods Rails gives you to interact with +However, due to the rich number of methods Rails gives you to interact with validations in general, it's fairly easy to build your own. In addition, when generating a scaffold, Rails will put some ERB into the `_form.html.erb` that it generates that displays the full list of errors on that model. diff --git a/guides/source/caching_with_rails.md b/guides/source/caching_with_rails.md index e737dcab83..773102400a 100644 --- a/guides/source/caching_with_rails.md +++ b/guides/source/caching_with_rails.md @@ -104,7 +104,7 @@ Let's say you only wanted authenticated users to call actions on `ProductsContro ```ruby class ProductsController < ActionController - before_filter :authenticate + before_action :authenticate caches_action :index def index diff --git a/guides/source/i18n.md b/guides/source/i18n.md index 1131b7f245..399a4963d7 100644 --- a/guides/source/i18n.md +++ b/guides/source/i18n.md @@ -134,10 +134,10 @@ However, you would probably like to **provide support for more locales** in your WARNING: You may be tempted to store the chosen locale in a _session_ or a <em>cookie</em>, however **do not do this**. The locale should be transparent and a part of the URL. This way you won't break people's basic assumptions about the web itself: if you send a URL to a friend, they should see the same page and content as you. A fancy word for this would be that you're being [<em>RESTful</em>](http://en.wikipedia.org/wiki/Representational_State_Transfer. Read more about the RESTful approach in [Stefan Tilkov's articles](http://www.infoq.com/articles/rest-introduction). Sometimes there are exceptions to this rule and those are discussed below. -The _setting part_ is easy. You can set the locale in a `before_filter` in the `ApplicationController` like this: +The _setting part_ is easy. You can set the locale in a `before_action` in the `ApplicationController` like this: ```ruby -before_filter :set_locale +before_action :set_locale def set_locale I18n.locale = params[:locale] || I18n.default_locale @@ -160,7 +160,7 @@ One option you have is to set the locale from the domain name where your applica You can implement it like this in your `ApplicationController`: ```ruby -before_filter :set_locale +before_action :set_locale def set_locale I18n.locale = extract_locale_from_tld || I18n.default_locale @@ -203,7 +203,7 @@ This solution has aforementioned advantages, however, you may not be able or may ### Setting the Locale from the URL Params -The most usual way of setting (and passing) the locale would be to include it in URL params, as we did in the `I18n.locale = params[:locale]` _before_filter_ in the first example. We would like to have URLs like `www.example.com/books?locale=ja` or `www.example.com/ja/books` in this case. +The most usual way of setting (and passing) the locale would be to include it in URL params, as we did in the `I18n.locale = params[:locale]` _before_action_ in the first example. We would like to have URLs like `www.example.com/books?locale=ja` or `www.example.com/ja/books` in this case. This approach has almost the same set of advantages as setting the locale from the domain name: namely that it's RESTful and in accord with the rest of the World Wide Web. It does require a little bit more work to implement, though. diff --git a/guides/source/security.md b/guides/source/security.md index 6c32a8ff5b..532a1ae5cc 100644 --- a/guides/source/security.md +++ b/guides/source/security.md @@ -688,7 +688,7 @@ NOTE: _When sanitizing, protecting or verifying something, whitelists over black A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although sometimes it is not possible to create a whitelist (in a SPAM filter, for example), _prefer to use whitelist approaches_: -* Use before_filter only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions. +* Use before_action only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions. * Use attr_accessible instead of attr_protected. See the mass-assignment section for details * Allow <strong> instead of removing <script> against Cross-Site Scripting (XSS). See below for details. * Don't try to correct user input by blacklists: |