The default controller scaffolding currently sends back a 302 for its
destroy action.
Since Hotwire is the default for Rails going forward, this can be
problimatic. Turbo uses the fetch API internally which is particular on
how it handles redirects.
As outlined in this table in this Turbo issue,
https://github.com/hotwired/turbo/issues/84#issuecomment-862656931,
Turbo making a DELETE request (not POST + hidden _method field) and
recieving a 302 back will result in another DELETE request instead of a
GET request for the redirect.
This updates the controller template used for the scaffold generator
to send back the 303 see other status code for the destroy action.
For consistancy-sake, the Action Controller Overview guide examples
were also updated. The main Getting Started guide page already has
see other used in its example destroy action.
For non-Hotwire users, the browser will still properly redirect on
a 303 as it does with a 302.
activerecord-session_store was removed in 0ffe190, and has been
displaying a special error message when missing since Rails 4.0.
Replace the specific error message so that third party stores get nicer
error handling as well
Since #43138, each config setting has its own linkable section in the
configuration guide.
This commit links config settings throughout the guides to their
sections in the configuration guide.
The `filter_parameters` configuration includes a list of filters in the
latest `filter_parameter_logging` initializer template.
This updates the guides to reflect those changes.
In both Rails 5.2 and Rails 6.1, defining a controller action method
named `config` will result in a `SystemStackError: stack level too deep`
exception for all requests routed to that controller. This is because
`ActiveSupport` defines `ActiveSupport::Configurable#config` which is
included into `ActionController::Base` by default, and the new config
action overrides it. Any actions in the controller will call `render`
which eventually will call `logger` which is a configurable attribute
which calls `config` which then calls the new `config` action which
calls `render` and so on. `config` is not the only method that will
trigger this behavior if redefined in a controller: In Rails 6.1, there
are 17 methods that would result in `SystemStackError` if redefined, 9
that would result in `ArgumentError`, and 3 that would result in a
`AbstractController::DoubleRenderError`. Most of these methods are
obvious that they should be avoided, like `render`, but some, including
`config` since it's never something the user would typically call
themselves and its buried deep down in some dependencies, are surprising
when encountered and the `SystemStackError` that simply points back to
the action method isn't very helpful when trying to debug what has
happened.
This commit updates the ActionController Overview section of the Guide
to add a note about the potential for this conflict, but stops short of
a full list of reserved methods since it's a.) lengthy, and b.) likely
to change as internal APIs are updated.
Closes to https://github.com/rails/rails/issues/41323
`form_with` would generate a remote form by default.
This confused users because they were forced to handle remote requests.
All new 6.1 applications will generate non-remote forms by default.
When upgrading a 6.0 application you can enable remote forms by default by
setting `config.action_view.form_with_generates_remote_forms` to `true`.
This links the first mention of each method to its API documentation,
similar to a Wikipedia article. Some subsequent mentions are also
linked, when it suits the surrounding text.
This also modifies the text in a few places to ensure that methods are
explicitly mentioned (and linked) before they appear in code examples.
Follow-up to #39594, which added CSS in order to select shell commands
sans prompts on triple-click.
This commit adds several bash code fences and prompts where they were
missing, and removes a few where they were inappropriate.
Examples for flash and session had code that would generally
raise ForbiddenAttributesErrors. Tweak the examples to avoid
this potentially misleading example. [ci skip]
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`.
