| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
supports it.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
|\
| |
| |
| |
| | |
albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails
Prefer rails command over bin/rails
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
| |
http links will be redirected to the https version, but still better to
just directly link to the https version.
|
|
|
|
|
|
|
| |
[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) "
|
|
|
|
| |
* The twitter developer site's url was changed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
| |
PUBLISHED ON http://guides.rubyonrails.org.**
|
| |
|
|
|
|
| |
* `MyApi::Application::Routes` is not middleware.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
| |
[ci skip]
|
|\
| |
| |
| |
| | |
Conflicts:
guides/source/configuring.md
|
| |
| |
| |
| |
| |
| | |
ActionController::Metal.ancestors` command for api apps.
[ci skip]
|
| |
| |
| |
| | |
vs configuring the server itself
|
| |
| |
| |
| |
| |
| |
| | |
guides [ci skip]
Guides should be updated because ActionDispatch::LoadInterlock was replaced with
ActionDispatch::Executor at #23807.
|
|/ |
|
|\
| |
| |
| |
| | |
Conflicts:
guides/source/configuring.md
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| | |
for normal apps.
[ci skip]
|
|/
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
| |
documentation.
- #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.
|
| |
|
|
|
|
| |
[ci skip]
|
|\
| |
| | |
Update middleware docs regarding ActionDispatch::LoadInterlock [ci skip]
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Pass through correcting api_app.md. The list of included modules and
middleware was tested through a sample API app, and was listed in the
same order an end user would see in their terminal.
[ci skip]
|
| |
| |
| |
| |
| |
| | |
It is not always there anymore
[ci skip]
|
|/
|
|
| |
[ci skip]
|
|
|
|
| |
Still more to do. Please assist!
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 37423e4ff883ad5584bab983aceb4b2b759a1fd8.
Jeremy is right that we shouldn't remove this. The fact is that many
engines are depending on this middleware to be in the default stack.
This ties our hands and forces us to keep the middleware in the stack so
that engines will work. To be extremely clear, I think this is another
smell of "the rack stack" that we have in place. When manipulating
middleware, we should have meaningful names for places in the req / res
lifecycle **not** have engines depend on a particular constant be in a
particular place in the stack. This is a weakness of the API that we
have to figure out a way to address before removing the constant.
As far as timing attacks are concerned, we can reduce the granularity
such that it isn't useful information for hackers, but is still useful
for developers.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The runtime header is a potential target for timing attacks since it
returns the amount of time spent on the server (eliminating network
speed). Total time is also not accurate for streaming responses.
The middleware can be added back via:
```ruby
config.middleware.ues ::Rack::Runtime
```
|
|
|
|
|
| |
This can still be added to the middleware stack, but is really not
necessary. I'll follow up with a commit that deprecates the constant
|
| |
|
|
|
|
|
|
| |
Since all controller instances are required to have a request and
response object, RackDelegation is no longer needed (we always have to
delegate to the response)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Fix a few remaining typos
* Wrap lines to 80 chars
* Fix the conversion from Textile to Markdown
* Update the part about `Rack::Cache` which isn't included anymore and
speak about Active Support's provided middleware
* Remove references to out-of-date methods and middlewares (e.g.
respond_with) and update the list of modules and middlewares to match
the actual code-base.
* Remove the middleware's description and links to the Rack guide
|
| |
|
| |
|
|
|