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.
We were planning to remove this middleware because we thought it could
make easier to attacker to do a Time Attack. However, while
Rack::Runtime can indeed be used to know how long a request took, and
compare with other requests, it doesn't provide any information that
can't be found in the total time of the request as well.
Instead of removing the middleware, we decided to keep it, and direct
users to instead of removing it, use its information to uncover actions
that are vulnerable to Time Attack.
This reverts commit 127dd06df66552dd272eea7832f8bb205cf6fd01, reversing
changes made to 4354e3ae492e95934a6da4101556a05d20b9f897.
Previous discussion: #38412, #38325, 37423e4, 24f9c03
- Rack::Runtime is replaced by FakeRuntime, which is a dummy middleware
that just passes requests on and cannot be used in middleware operations
- Using Rack::Runtime in middleware operations (relative inserts, moves,
etc.) throws a deprecation warning and uses FakeRuntime instead
- if an application adds Rack::Runtime explicitly (use, unshift, etc.),
then the deprecation warning does not happen and FakeRuntime is
ignored
- docs are updated to no longer reference Rack::Runtime
The GitHub gist API page is out of date. This commit replaces it with
the new link.
Also, removed unnecessary commas, added missing fullstop and fixed
a ruby snippet which wasn't rendered correctly before.
- Using `mem_cached_store` results in an exception as lib/active_support/cache.rb:106:in `rescue in retrieve_store_class': Could not find cache store adapter for mem_cached_store (cannot load such file -- active_support/cache/mem_cached_store) (RuntimeError)
- Changed the name of cache_store as `mem_cache_store` instead of `mem_cached_store`
Rails doesn't support view caching in api controllers by default but the
document didn't clearerly declare this nor the manual config needed
after including the module manually. So we'll see people get confused
like #35602.
During the development of #33145, I have named a few concepts in the
code as `whitelisted`. We decided to stay away from the term and I
adjusted most of the code afterwards, but here are the cases I forgot to
change.
I also found a case in the API guide that we could have cleaned up as
well.
[ci skip]
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.
[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) "
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`.
* Adjust list of middlewares loaded by default
* Add routing middleware to list to match the list in the Rack guide
* Adjust list of Controller modules loaded by default
Plus fix one singular/plural mistake
- #23771 removed the reference to debug_exception_response_format from the api_app documentation.
- We need to let users know, they have ability to configure debug_exception_response_format in their development environment.
- Added documentation for the same in api_app.md file
- Grammar corrections
Since a0343d11f1bf80a79e273c1d0cf9934ef2601e98, `debug_exception_response_format` config depends on `api_only`.
Therefore, if set the `api_only`, need to specify `debug_exception_response_format` is not.
