This commit adds a test to ensure the behavior of inline `around_action`
calls, as well as a change to the guides to call out this alternate use of
`around_action`.
Closes#37616
As discussed in #33203 rails command already looks for, and runs,
bin/rails if it is present.
We were mixing recommendations within guides and USAGE guidelines,
in some files we recommended using rails, in others bin/rails and
in some cases we even had both options mixed together.
Since the ability to whitelist arbitrary hashes was added (https://github.com/rails/rails/issues/9454 was resolved by e86524c0c5), this example is no longer outside of what strong_params can do. Moved this specific example out of the "Outside the Scope" section and into the regular "Examples" section, but left the "Outside the Scope" section as it was since the advice is still relevant for weirder whitelisting situations (maybe someone wants to add a new example that can't be handled natively).
[ci skip] A regular expression was used to find a lot of missing Oxford
commas and add them. The regular expression was as follows.
", ([a-zA-Z0-9.\`:'\"]+ ){1,6}(or|and) "
After #31685 the description says different what
we expect to see in the example. Change `assign that key to be nil` to
`or delete the key/value pair` in order to highlight what is shown in the example.
Fix one more example of removing data from the session in favour of using
`delete` since assigning to `nil` doesn't delete key from it.
* Remove key from session by using session.delete
You are not deleting a key from session when you assign nil to that key.
* Update guides on how to destroy a user session
In this commit, the user id is removed from session and controller's variables related to the user are nullified.
[Rafael Mendonça França + Rafael Barbolo]
Today there are two common ways for Rails developers to force their
applications to communicate over HTTPS:
* `config.force_ssl` is a setting in environment configurations that
enables the `ActionDispatch::SSL` middleware. With this middleware
enabled, all HTTP communication to your application will be redirected
to HTTPS. The middleware also takes care of other best practices by
setting HSTS headers, upgrading all cookies to secure only, etc.
* The `force_ssl` controller method redirects HTTP requests to certain
controllers to HTTPS.
As a consultant, I've seen many applications with misconfigured HTTPS
setups due to developers adding `force_ssl` to `ApplicationController`
and not enabling `config.force_ssl`. With this configuration, many
application requests can be served over HTTP such as assets, requests
that hit mounted engines, etc. In addition, because cookies are not
upgraded to secure only in this configuration and HSTS headers are not
set, it's possible for cookies that are meant to be secure to be sent
over HTTP.
The confusion between these two methods of forcing HTTPS is compounded
by the fact that they share an identical name. This makes finding
documentation on the "right" method confusing.
HTTPS throughout is quickly becomming table stakes for all web sites.
Sites are expected to operate over HTTPS for all communication,
sensitive or otherwise. Let's encourage use of the broader-reaching
`ActionDispatch::SSL` middleware and elminate this source of user
confusion. If, for some reason, applications need to expose certain
endpoints over HTTP they can do so by properly configuring
`config.ssl_options`.
According to #30067:
> This PR will deprecate secrets.yml* and instead adopt
> config/credentials.yml.enc to signify what these secrets are specifically
> for: Keeping API keys, database passwords, and any other integration
> credentials in one place.
[ci skip] since only comments are being edited.
Adds a hint that ``after_action``-callbacks are not executed when an
exception was raised in the rest of the request cycle. The
``before_action`` section mentions "If there are additional filters
scheduled to run after that filter, they are also cancelled." but this
is IMO not sufficient.
- By default the session store will be set to cookie store with
application name as session key.
- Older apps are not affected as they will have the session store
initializer generated by Rails in older versions, and Rails will not
overwrite the session store if it is already set or disabled.
- But new apps will not have the initializer, instead the session store
will be set to cookie store by default.
- Based on comment by DHH here - https://github.com/rails/rails/issues/25181#issuecomment-222312764.
`redirect_to :back` is a somewhat common pattern in Rails apps, but it
is not completely safe. There are a number of circumstances where HTTP
referrer information is not available on the request. This happens often
with bot traffic and occasionally to user traffic depending on browser
security settings.
When there is no referrer available on the request, `redirect_to :back`
will raise `ActionController::RedirectBackError`, usually resulting in
an application error.
`redirect_back` takes a required `fallback_location` keyword argument
that specifies the redirect when the referrer information is not
available. This prevents 500 errors caused by
`ActionController::RedirectBackError`.
