-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ci skip] change all instances of blacklist and whitelist to denylist… #33681
[ci skip] change all instances of blacklist and whitelist to denylist… #33681
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no reason to believe they wouldn't, but a reading of this change shows that the grammar and code examples don't functionally change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much for working on this. I totally agree with the reasons for changing those terms.
I think we can improve most of those texts with different words than allowedlist
. I made some comments with suggestions but I didn't got to review the whole patch with suggestion to avoid put a lot of comments.
Can you review the changes to make the text to look more fluid?
guides/source/4_0_release_notes.md
Outdated
@@ -70,7 +70,7 @@ Major Features | |||
|
|||
### ActionPack | |||
|
|||
* **Strong parameters** ([commit](https://github.com/rails/rails/commit/a8f6d5c6450a7fe058348a7f10a908352bb6c7fc)) - Only allow whitelisted parameters to update model objects (`params.permit(:title, :text)`). | |||
* **Strong parameters** ([commit](https://github.com/rails/rails/commit/a8f6d5c6450a7fe058348a7f10a908352bb6c7fc)) - Only allow allowlisted parameters to update model objects (`params.permit(:title, :text)`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe: Only allow trusted parameters to updated model objects?
guides/source/4_1_release_notes.md
Outdated
@@ -719,7 +719,7 @@ for detailed changes. | |||
responsibilities within a | |||
class. ([Commit](https://github.com/rails/rails/commit/1eee0ca6de975b42524105a59e0521d18b38ab81)) | |||
|
|||
* Added `Object#presence_in` to simplify value whitelisting. | |||
* Added `Object#presence_in` to simplify value allowlisting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"allowing values" maybe?
@@ -193,7 +193,7 @@ In a given request, the method is not actually called for every single generated | |||
|
|||
With strong parameters, Action Controller parameters are forbidden to | |||
be used in Active Model mass assignments until they have been | |||
whitelisted. This means that you'll have to make a conscious decision about | |||
allowlisted. This means that you'll have to make a conscious decision about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"allowed" seems better here.
@@ -269,7 +269,7 @@ but be careful because this opens the door to arbitrary input. In this | |||
case, `permit` ensures values in the returned structure are permitted | |||
scalars and filters out anything else. | |||
|
|||
To whitelist an entire hash of parameters, the `permit!` method can be | |||
To allowlist an entire hash of parameters, the `permit!` method can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To allow
@@ -291,7 +291,7 @@ params.permit(:name, { emails: [] }, | |||
{ family: [ :name ], hobbies: [] }]) | |||
``` | |||
|
|||
This declaration whitelists the `name`, `emails`, and `friends` | |||
This declaration allowlists the `name`, `emails`, and `friends` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allow
guides/source/configuring.md
Outdated
@@ -275,7 +275,7 @@ config.middleware.delete Rack::MethodOverride | |||
|
|||
All these configuration options are delegated to the `I18n` library. | |||
|
|||
* `config.i18n.available_locales` whitelists the available locales for the app. Defaults to all locale keys found in locale files, usually only `:en` on a new application. | |||
* `config.i18n.available_locales` allowlists the available locales for the app. Defaults to all locale keys found in locale files, usually only `:en` on a new application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
defines
guides/source/configuring.md
Outdated
@@ -444,7 +444,7 @@ The schema dumper adds two additional configuration options: | |||
|
|||
* `config.action_controller.action_on_unpermitted_parameters` enables logging or raising an exception if parameters that are not explicitly permitted are found. Set to `:log` or `:raise` to enable. The default value is `:log` in development and test environments, and `false` in all other environments. | |||
|
|||
* `config.action_controller.always_permitted_parameters` sets a list of whitelisted parameters that are permitted by default. The default values are `['controller', 'action']`. | |||
* `config.action_controller.always_permitted_parameters` sets a list of allowlisted parameters that are permitted by default. The default values are `['controller', 'action']`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowed
@@ -888,7 +888,7 @@ do that with `local_variables`. | |||
|
|||
### Settings | |||
|
|||
* `config.web_console.whitelisted_ips`: Authorized list of IPv4 or IPv6 | |||
* `config.web_console.allowlisted_ips`: Authorized list of IPv4 or IPv6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one we can't change without changing the web_console too and allowed_ips
sounds better.
guides/source/form_helpers.md
Outdated
@@ -999,7 +999,7 @@ remove addresses: | |||
<% end %> | |||
``` | |||
|
|||
Don't forget to update the whitelisted params in your controller to also include | |||
Don't forget to update the allowlisted params in your controller to also include |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowed
guides/source/form_helpers.md
Outdated
@@ -953,7 +953,7 @@ If the associated object is already saved, `fields_for` autogenerates a hidden i | |||
### The Controller | |||
|
|||
As usual you need to | |||
[whitelist the parameters](action_controller_overview.html#strong-parameters) in | |||
[allowlist the parameters](action_controller_overview.html#strong-parameters) in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allow maybe?
@rafaelfranca Thanks for combing through for those awkward grammar. I've fixed all of them, mostly with your suggestion in the new commit. |
@@ -1200,7 +1200,7 @@ to the database as `NULL` instead of passing the `nil` value through YAML (`"--- | |||
* Rails 4.0 has removed `attr_accessible` and `attr_protected` feature in favor of Strong Parameters. You can use the [Protected Attributes gem](https://github.com/rails/protected_attributes) for a smooth upgrade path. | |||
|
|||
* If you are not using Protected Attributes, you can remove any options related to | |||
this gem such as `whitelist_attributes` or `mass_assignment_sanitizer` options. | |||
this gem such as `allowlist_attributes` or `mass_assignment_sanitizer` options. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we cannot change this unless we change Protected Attributes gem.
@@ -999,7 +999,7 @@ remove addresses: | |||
<% end %> | |||
``` | |||
|
|||
Don't forget to update the whitelisted params in your controller to also include | |||
Don't forget to update the permitted params in your controller to also include |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By renaming whitelist to a mixture of:
- permitted
- allowed
- trusted
we're only creating more confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could reword this to consistently use "permit" or "permitted".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tenderlove Roger that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some comments. I really like this change, but I think we should try to consistently use "permitted" (consistency should help people reading the docs, plus it shares the name of the method). "Denylist" seems kind of awkward, but I'm having a hard time thinking of an antonym for "permit" besides "deny". 😊
@@ -193,7 +193,7 @@ In a given request, the method is not actually called for every single generated | |||
|
|||
With strong parameters, Action Controller parameters are forbidden to | |||
be used in Active Model mass assignments until they have been | |||
whitelisted. This means that you'll have to make a conscious decision about | |||
allowed. This means that you'll have to make a conscious decision about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be "what is allowed" (or "what is permitted")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"...until they have been what is permitted." doesn't seem to make sense. 🤔
@@ -241,7 +241,7 @@ Given | |||
params.permit(:id) | |||
``` | |||
|
|||
the key `:id` will pass the whitelisting if it appears in `params` and | |||
the key `:id` will pass the allowlisting if it appears in `params` and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the key
:id
will be permitted if it appears inparams
and
or possibly
the key
:id
will be permitted for inclusion if it appears inparams
and
@@ -349,7 +349,7 @@ end | |||
|
|||
The strong parameter API was designed with the most common use cases | |||
in mind. It is not meant as a silver bullet to handle all of your | |||
whitelisting problems. However, you can easily mix the API with your | |||
allowlisting problems. However, you can easily mix the API with your |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
parameter filtering problems.
guides/source/getting_started.md
Outdated
assignment. In this case, we want to both allow and require the `title` and | ||
`text` parameters for valid use of `create`. The syntax for this introduces | ||
`require` and `permit`. The change will involve one line in the `create` action: | ||
We have to define our permitted controller parameters to prevent wrongful mass assignment. In this case, we want to both allow and require the `title` and `text` parameters for valid use of `create`. The syntax for this introduces `require` and `permit`. The change will involve one line in the `create` action: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this paragraph needs to be wrapped
guides/source/i18n.md
Outdated
@@ -77,8 +77,8 @@ There are also attribute readers and writers for the following attributes: | |||
load_path # Announce your custom translation files | |||
locale # Get and set the current locale | |||
default_locale # Get and set the default locale | |||
available_locales # Whitelist locales available for the application | |||
enforce_available_locales # Enforce locale whitelisting (true or false) | |||
available_locales # Allowlist locales available for the application |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Allowlist/Permitted/
guides/source/i18n.md
Outdated
@@ -128,7 +128,7 @@ The load path must be specified before any translations are looked up. To change | |||
# Where the I18n library should search for translation files | |||
I18n.load_path += Dir[Rails.root.join('lib', 'locale', '*.{rb,yml}')] | |||
|
|||
# Whitelist locales available for the application | |||
# Allowlist locales available for the application |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/Allowlist/Permitted/
@tenderlove How do you feel about "restricted list" or "restrict" as an alternative? |
Sounds good to me! 😄 |
…restricted list and consistently use permitted
### Summary Follow up rubocop#6464, rubocop#6466, and rubocop#6467. This PR changes a terminology from `Whitelist` and `Blacklist` to `Allowlist` and `Denylist`. This change is an obvious breaking change to some cop options. So I'd like to introduce it before RuboCop 1.0 if this change is acceptable. ### Other Information This change has also been made in Rails repository and other repos. rails/rails#33681
### Summary Follow up #6464, #6466, and #6467. This PR changes a terminology from `Whitelist` and `Blacklist` to `Allowlist` and `Denylist`. This change is an obvious breaking change to some cop options. So I'd like to introduce it before RuboCop 1.0 if this change is acceptable. ### Other Information This change has also been made in Rails repository and other repos. rails/rails#33681
Use terminology which is more descriptive and is consistent with the direction of some upstream libraries: rubocop/rubocop#6467 rails/rails#33681
Use terminology which is more descriptive and is consistent with the direction of some upstream libraries: rubocop/rubocop#6467 rails/rails#33681
Use terminology which is more descriptive and is consistent with the direction of some upstream libraries: rubocop/rubocop#6467 rails/rails#33681
Use terminology which is more descriptive and is consistent with the direction of some upstream libraries: rubocop/rubocop#6467 rails/rails#33681
Use terminology which is more descriptive and is consistent with the direction of some upstream libraries: rubocop/rubocop#6467 rails/rails#33681
Use terminology which is more descriptive and is consistent with the direction of some upstream libraries: rubocop/rubocop#6467 rails/rails#33681
… and allowlist
Summary
Per DHH, changed occurrence of "blacklist" to "denylist" and "whitelist" to "allowlist" in Rails documentation files. This pull request closes this issue.
Other Information
Adhering to information from the contribution guidelines re: documentation changes, only files in
rails/guides/source
were changed.Finally, if your pull request affects documentation or any non-code
changes, guidelines for those changes are available
here
Thanks for contributing to Rails!