| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ /
| |
| |
| |
| |
| | |
Related with 38d2bf5fd1f3e014f2397898d371c339baa627b1.
cc @tenderlove
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[ci skip]
This updates the 5.0 release notes guide to reflect changes that
happened after beta1 has been released.
I'll sync the other changelogs later today but I'll push this batch to
prevent against cumbersome merge conflicts.
|
|\ \
| | |
| | |
| | | |
Default rendering behavior if respond_to collector doesn't have a block.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a `respond_to` collector doesn't have a response, then a
`:no_content` response should be rendered. This brings the default
rendering behavior introduced by
https://github.com/rails/rails/issues/19036 to controller methods
employing `respond_to`
|
| | |
| | |
| | |
| | |
| | |
| | | |
This method will only be added when used with Ruby 2.3.0 or greater.
This method has the same behavior as `Hash#dig`, except it will convert
hashes to `ActionController::Parameters`, similar to `#[]` and `#fetch`.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
Prevent not-intended loading of `ActionDispatch::IntegrationTest`
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
After 9d378747326d26cf1afdac4433ead22967af0984 `ActionDispatch::IntegrationTest`
class is loaded and defined in all Rails environments, not only test but also
production. This is not-intended loading of a class which is only used in
test environment.
To prevent not-intended loading, add `ActiveSupport.run_load_hooks` to
`ActionDispatch::IntegrationTest` with `action_dispatch_integration_test` name
and use it in `ActionMailer`.
|
|/ /
| |
| |
| |
| |
| |
| | |
This reverts commit 22db455dbe9c26fe6d723cac0758705d9943ea4b, reversing
changes made to 40be61dfda1e04c3f306022a40370862e3a2ce39.
This finishes off what I meant to do in 6216a092ccfe6422f113db906a52fe8ffdafdbe6.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Conceptually revert #20276
The feature was implemented for the `responders` gem. In the end,
they did not need that feature, and have found a better fix (see
plataformatec/responders#131).
`ImplicitRender` is the place where Rails specifies our default
policies for the case where the user did not explicitly tell us
what to render, essentially describing a set of heuristics. If
the gem (or the user) knows exactly what they want, they could
just perform the correct `render` to avoid falling through to
here, as `responders` did (the user called `respond_with`).
Reverting the patch allows us to avoid exploding the complexity
and defining “the fallback for a fallback” policies.
2. `respond_to` and templates are considered exhaustive enumerations
If the user specified a list of formats/variants in a `respond_to`
block, anything that is not explicitly included should result
in an `UnknownFormat` error (which is then caught upstream to
mean “406 Not Acceptable” by default). This is already how it
works before this commit.
Same goes for templates – if the user defined a set of templates
(usually in the file system), that set is now considered exhaustive,
which means that “missing” templates are considered `UnknownFormat`
errors (406).
3. To keep API endpoints simple, the implicit render behavior for
actions with no templates defined at all (regardless of formats,
locales, variants, etc) are defaulted to “204 No Content”. This
is a strictly narrower version of the feature landed in #19036 and
#19377.
4. To avoid confusion when interacting in the browser, these actions
will raise an `UnknownFormat` error for “interactive” requests
instead. (The precise definition of “interactive” requests might
change – the spirit here is to give helpful messages and avoid
confusions.)
Closes #20666, #23062, #23077, #23564
[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]
|
| |
| |
| |
| | |
Adds changelog headers for beta3 release
|
| |
| |
| |
| |
| |
| |
| | |
It is not a released feature so we don't need to add changelogs to
changes on it.
[ci skip]
|
| |
| |
| |
| | |
- Fixes #23822.
|
|\ \
| | |
| | |
| | | |
Give Sessions Indifferent Access
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Yesterday, when improving how `parsed_body` extracted a parser I wrote
77bbf1e. Then I thought that was too many changes in one commit
and broke it up locally... or so I thought.
When pushed the extra commits removed the changes! Wups!
In shame, lob those changes together here:
* 3b94c38 which meant to fix the CHANGELOG syntax error.
* 5007df5 which meant to mention `parsed_body` in the docs.
* 036a7a0 which meant to memoize the `parsed_body`.
|
| |
| |
| |
| |
| |
| |
| | |
Add more info about the APIs added and how they work.
Use string keys when comparing the parsed response, like how JSON would
be parsed.
|
| |
| |
| | |
since starting with Rails 5.x(beta) we prefer to use rails as the replacement of rake commands, may be change log will be the same
|
| |
| |
| |
| |
| |
| | |
- Fixed related documentation and usage all around
Fixes #23561
|
| |
| |
| |
| |
| | |
Forgot to add this in the original pull request. No biggie, just show
some examples.
|
| | |
|
| |
| |
| | |
fix indentation to show it as code
|
| |
| |
| |
| |
| |
| | |
And improve changelongs.
[ci skip]
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
Add two options: `-c` and `-g`.
`-g` option returns the urls name, verb and path fields that match the pattern.
`-c` option returns the urls for specific controller.
Fixes #18902, and Fixes #20420
[Anton Davydov & Vipul A M]
|
|
|
|
|
|
| |
Based on https://github.com/rails/rails/pull/23167/files#r50507317
[ci skip]
|
|
|
|
| |
See bug #21032.
|
|
|
|
| |
ActionDispatch::Http::Cache::Response#etag= such that etags set in fresh_when and stale? are weak. For #17556.
|
| |
|
| |
|
|
|
|
|
| |
Also, refactor logic to convert between symbol and response code,
via the AssertionResponse class
|
| |
|
| |
|
|
|
|
|
|
|
| |
- `CONTROLLER` argument can now be supplied in different ways (Rails::WelcomeController, Rails::Welcome, rails/welcome)
- If `CONTROLLER` argument was supplied but it does not exist, will warn the user that this controller does not exist
- If `CONTROLLER` argument was supplied and no routes could be found matching this filter, will warn the user that no routes were found matching the supplied filter
- If no routes were defined in the config/routes.rb file, will warn the user with the original message
|
|
|
|
|
|
|
|
| |
- Earlier only Hash was allowed as params argument to url_helpers.
- Now ActionController::Parameters instances will also be allowed.
- If the params are not secured then it will raise an ArgumentError to
indicate that constructing URLs with non-secure params is not recommended.
- Fixes #22832.
|
| |
|
| |
|
|
|
|
|
|
|
| |
- AC::Parameters#convert_parameters_to_hashes should return filtered or
unfiltered values based on whether it is called from `to_h` or `to_unsafe_h`
instead of always defaulting to `to_h`.
- Fixes #22841
|
|
|
|
| |
Fixes #22818
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the `5.0.0.beta1` release, the CHANGELOGs got an entry like the
following:
```
* No changes.
```
It is kinda confusing as there are indeed changes after it. Not a
biggie, just a small pass over the CHANGELOGs.
[ci skip]
|
| |
|
|
|
|
|
|
|
| |
Applications that use `redirect_to :back` can be forced to 500 by
clients that do not send the HTTP `Referer` (sic) header.
`redirect_back` requires the user to consider this possibility up front
and avoids this trivially-caused application error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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`.
|
|
|
|
| |
So that it appears correctly in the CHANGELOG on github.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Rails 5.1 `ActionController::TestCase` will be moved out of Rails
into it's own gem.
Please use `ActionDispatch::IntegrationTest` going foward.
Because this will be moved to a gem I used `# :stopdoc:` instead of
deleting the documentation. This will remove it from the Rails
documentation but still leave the method documented for when we move it
to a gem.
Guides have been updated to use the routing structure used in Integration
and all test examples have been updated to inherit from
`ActionDispatch::IntegrationTest` instead of `ActionController::TestCase.
Fixes #22496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per this comment
https://github.com/rails/rails/pull/18334#issuecomment-69234050 we want
`protect_from_forgery` to default to `prepend: false`.
`protect_from_forgery` will now be insterted into the callback chain at the
point it is called in your application. This is useful for cases where you
want to `protect_from_forgery` after you perform required authentication
callbacks or other callbacks that are required to run after forgery protection.
If you want `protect_from_forgery` callbacks to always run first, regardless of
position they are called in your application, then you can add `prepend: true`
to your `protect_from_forgery` call.
Example:
```ruby
protect_from_forgery prepend: true
```
|