Commit 20fece1 introduced the `_status_code` method to fix calls to
`head :ok`. This method has been added on both ActionController::Metal
and ActionDispatch::Response.
As for the latter, this method is just equivalent to the `response_code`
one so commit aefec3c removed it from the `Reponse` object so call to
the `_status_code` method on an ActionController::Base instance would be
handled by the `Metal` class (which `Base` inherits from) but the status
code is not updated according to the response at this level.
The fix is to actually rely on `response_code` for ActionController::Base
instances but this method doesn't exist for bare Metal controllers so we
need to define it.
Previously, if you tried to use form_for with a presenter object
that implements to_model, it would crash in
action_dispatch/routing/polymorphic_routes.rb when asking the presenter
whether it is .persisted?
Now, we always ask .persisted? of the to_model object instead.
This seems to been an issue since 1606fc9d840da869a60213bc889da6fcf1fdc431
Signed-off-by: Eugenia Dellapenna <eugenia.dellapenna@gmail.com>
existing example. [ci skip]
My reasoning is that this is probably too much information for the complete
Rails testing guide, as we're trying to cover testing all aspects of the
framework.
The methods in these modules are not used anywhere. They used to be
invoked in polymorphic_routes.rb but their usage was removed in e821045.
What is your opinion about removing these methods?
They do belong to the public API, but in reality their code has already been duplicated to ActionView::ModelNaming, since they are used by methods like `dom_id` and `dom_class` to associated records with DOM elements (in
ActionView).
Please tell me if you think that removing this module is a good idea and,
in that case, if the PR is okay as it is, or you'd rather start by showing
a deprecation message, and remove the module in Rails 5.1.
The current implementation of `variants=` don't allow a resetting to nil, wich is the default value.
This results in the following code smell:
```ruby
case request.user_agent
when /iPhone/
request.variants = :phone
when /iPad/
request.variants = :ipad
end
```
With the ability to reset variants to nil, it could be:
```ruby
request.variants = case request.user_agent
when /iPhone/
:phone
when /iPad/
:ipad
end
```
There is no need to subtract one from the path_params size when there is
no format parameter because it is not present in the path_params array.
Fixes#17819.
As suggested in #16299([1]), this method should be a new public API for
retrieving unfiltered parameters from `ActionController::Parameters`
object, given that `Parameters#to_hash` will no longer work in Rails
5.0+ as we stop inheriting `Parameters` from `Hash`.
[1]: https://github.com/rails/rails/pull/16299#issuecomment-50220919
This fixes a regression in 4.2.0 from 4.1.8.
https://github.com/rails/rails/pull/17823 fixed a similar regression regarding _explicitly_ named routes for a mounted Rack app, but there was another regression for the default value.
With a route like:
Rails.application.routes.draw do
mount Mountable::Web, at: 'some_route'
end
The "Prefix" column of rake routes gives the following:
- 4.1.8: mountable_web
- 4.2.0.beta1-4: [nothing]
- 4.2.0.rc1: [nothing]
- 4.2.0.rc2: some_route <- regression
This fixes the default to go back to being based off the name of the class like the docs specify: 785d04e310/actionpack/lib/action_dispatch/routing/mapper.rb (L558-L560)
Explicitly named routes still work correctly per https://github.com/rails/rails/pull/17823:
Rails.application.routes.draw do
mount Mountable::Web, at: 'some_route', as: 'named'
end
- 4.1.8: named
- 4.2.0.beta1-4: [nothing]
- 4.2.0.rc1: [nothing]
- 4.2.0.rc2: named
Closes#17615#17616
when script_name is nil in the options hash, script_name is set to nil.
options = {script_name: nil}
script_name = options.delete(:script_name) {‘’} # => nil
Signed-off-by: Santiago Pastorino <santiago@wyeworks.com>
This will help you debug missing template errors, especially if they
come from a programmatic template selection. Thanks to @dhh for
suggesting that.
As a bonus, also show request and response info on the routing error
page for consistency.
If the route set is empty, or if none of the routes matches with a score > 0,
there is no point showing the deprecation message because we are already be
raising the `ActionController::UrlGenerationError` mentioned in the warning.
In this case it is the expected behavior and the user wouldn't have to take any
actions.
The internal tests that (incorrectly) relied on this were already fixed in
938d130. However, we cannot simply fix this bug because the guides prior to
b7b9e92 recommended a workaround that relies on this buggy behavior.
Reference #17453
I grepped the source code for code snippets wrapped in backticks in the comments
and replaced the backticks with plus signs so they are correctly displayed in
the Rails documentation.
[ci skip]
This reverts commit f93df52845766216f0fe36a4586f8abad505cac4, reversing
changes made to a455e3f4e9dbfb9630d47878e1239bc424fb7d13.
Conflicts:
actionpack/lib/action_controller/test_case.rb
actionview/lib/action_view/test_case.rb
If a trace isn't an application one, then it comes from a framework.
That's the definition of framework trace. We can speed up the traces
generation if we don't double check that.
Since dbcbbcf2bc58e8971672b143d1c52c0244e33f26 the full trace is shown
by default on routing errors. While this is a nice feature to have, it
does take the attention off the routes table in this view and I think
this is what most of the people look for in this page.
Added an exception to the default trace switching rule to remove that
noise.
Those three can be nil when exception backtrace is nil. This happens and
that forced a couple of nil guards in the code. I'm proposing to make
those always return an array, even on nil backtrace.
Follow up to 212057b9. Since that commit, we need to pass the `route_name`
explicitly. This is one of the left-over cases that was not handled in that
commit, which was causing `use_route` to be ignored in functional tests.
- `secrets.secret_token` is now used in all places `config.secret_token` was
- `secrets.secret_token`, when not present in `config/secrets.yml`,
now falls back to the value of `config.secret_token`
- when `secrets.secret_token` is set, it over-writes
`config.secret_token` so they are the same (for backwards-compatibility)
- Update docs to reference app.secrets in all places
- Remove references to `config.secret_token`, `config.secret_key_base`
- Warn that missing secret_key_base is deprecated
- Add tests for secret_token, key_generator, and message_verifier
- the legacy key generator is used with the message verifier when
secrets.secret_key_base is blank and secret_token is set
- app.key_generator raises when neither secrets.secret_key_base nor
secret_token are set
- app.env_config raises when neither secrets.secret_key_base nor
secret_token are set
- Add changelog
Run focused tests via
ruby -w -Itest test/application/configuration_test.rb -n '/secret_|key_/'
This patch uniformizes warning messages. I used the most common style
already present in the code base:
* Capitalize the first word.
* End the message with a full stop.
* "Rails 5" instead of "Rails 5.0".
* Backticks for method names and inline code.
Also, converted a few long strings into the new heredoc convention.
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
In cases where this option is set to `true`, the option is redundant and can
be safely removed; otherwise, the corresponding `*_url` helper should be
used instead.
Fixes#17294.
See also #17363.
[Dan Olson, Godfrey Chan]
Performance optimization: `yield` with an implicit `block` is faster than `block.call`.
See http://youtu.be/fGFM_UrSp70?t=10m35s and the following benchmark:
```ruby
require 'benchmark/ips'
def fast
yield
end
def slow(&block)
block.call
end
Benchmark.ips do |x|
x.report('fast') { fast{} }
x.report('slow') { slow{} }
end
# => fast 154095 i/100ms
# => slow 71454 i/100ms
# =>
# => fast 7511067.8 (±5.0%) i/s - 37445085 in 4.999660s
# => slow 1227576.9 (±6.8%) i/s - 6145044 in 5.028356s
```
The scanner in Journey fails to recognize routes that use literals
from the sub-delims section of RFC 3986.
This commit enhance the compatibility of Journey with the RFC by
adding support of authorized delimiters to the scanner.
Fix#17212
Request#check_method would use to_sentence(locale: :en), which breaks when
I18n.available_locales does not include :en and
I18n.enforce_available_locales is true (default).
Inlined to_sentence functionality to solve this.
Hash#keys.each allocates an array of keys; Hash#each_key iterates through the
keys without allocating a new array. This is the reason why Hash#each_key
exists.
This reverts commit 9d05d6de52871e57bfbf54a60de005e8a5f5b0e4, reversing
changes made to 0863c9248fd47a15e88e05ce4fcd80966684c0e3.
The change in the behaviour reported at #16958 doesn't exist since 4.0
and 4.1 works in the same way
As of rack/rack@167b648023, Rack raises
Rack::Utils::ParameterTypeError which inherits TypeError.
In terms of the behavior, Rescuing TypeError still works but this
method shouldn't rescue if TypeError is raised for other reasons.
* Renames _handle_render_options to _render_to_body_with_renderer, which is more
intention-revealing.
* The name of the dynamically generated method for a renderer with key :js was
"_render_option_js".
That name is too weak. :js is an option if you see the render argument as just
a generic options hash, but in the context of renderers that's the renderer
key, is what identifies the renderer.
Now "_render_with_renderer_js" is generated instead, which is crystal clear.
* The name of the dynamically generated method for the renderer was constructed
using string literals in a few places. That is now encapsulated in a method.
* Since we were on it, also removed a couple of redundant selfs.
Suppose you have two resources routed in the following manner:
```ruby
resources :blogs do
resources :posts
end
resources :posts
```
When using polymorphic resource routing like `url_for([@blog, @post])`, and `@blog` is `nil` Rails should still try to match the route to the top-level posts resource.
Fixes#16754
When we are loading a component and we want to know its version, we are
actually not speaking about the constant but the library itself.
[ci skip]
[Godfrey Chan & Xavier Noria]
IPAddr::InvalidAddressError does not exist in Ruby 1.9.3
and fails for JRuby in 1.9 mode.
As IPAddr::InvalidAddressError is a subclass of ArgumentError
(via IPAddr::Error) just rescuing ArgumentError is fine.
Dir.glob can be a security concern. The original use was to provide logic of fallback files. Example a request to `/` should render the file from `/public/index.html`. We can replace the dir glob with the specific logic it represents. The glob {,index,index.html} will look for the current path, then in the directory of the path with index file and then in the directory of the path with index.html. This PR replaces the glob logic by manually checking each potential match. Best case scenario this results in one less file API request, worst case, this has one more file API request.
Related to #16464
Update: added a test for when a file of a given name (`public/bar.html` and a directory `public/bar` both exist in the same root directory. Changed logic to accommodate this scenario.
- don't mutate PATH_INFO in env, test
- test fallback content type matches Rack::File
- change assertion style
- make HTTP_ACCEPT_ENCODING comparison case insensitive
- return gzip path from method instead of true/false so we don't have to assume later
- don't allocate un-needed hash.
Original comments:
https://github.com/rails/rails/commit/
cfaaacd9763642e91761de54c90669a88d772e5a#commitcomment-7468728
cc @jeremy
Refactored IP address checking in ActionDispatch::RemoteIp to rely on
the IPAddr class instead of the unwieldly regular expression to match
IP addresses. This commit keeps the same api but allows users to pass
IPAddr objects to config.action_dispatch.trusted_proxies in addition
to passing strings and regular expressions.
Example:
# config/environments/production.rb
config.action_dispatch.trusted_proxies = IPAddr.new('4.8.15.0/16')
Follow up to rails#15321
Instead of duplicating the routes, we will first match the HEAD request to
HEAD routes. If no match is found, we will then map the HEAD request to
GET routes.
If someone is using ActionDispatch::Static to serve assets and makes it past the `match?` then the file exists on disk and it will be served. This PR adds in logic that checks to see if the file being served is already compressed (via gzip) and on disk, if it is it will be served as long as the client can handle gzip encoding. If not, then a non gzip file will be served.
This additional logic slows down an individual asset request but should speed up the consumer experience as compressed files are served and production applications should be delivered with a CDN. This PR allows a CDN to cache a gzip file by setting the `Vary` header appropriately. In net this should speed up a production application that are using Rails as an origin for a CDN. Non-asset request speed is not affected in this PR.
This merges in the code from the breach-mitigation-rails gem that masks
authenticity tokens on each request by XORing them with a random set of
bytes. The masking is used to make it impossible for an attacker to
steal a CSRF token from an SSL session by using techniques like the
BREACH attack.
The patch is pretty simple - I've copied over the [relevant
code](https://github.com/meldium/breach-mitigation-rails/blob/master/lib/breach_mitigation/masking_secrets.rb)
and updated the tests to pass, mostly by adjusting stubs and mocks.
This is to make sure that `permitted` status is maintained on the
resulting object.
I found these methods that needs to be redefined by looking for
`self.class.new` in the code.
* extract!
* transform_keys
* transform_values
`ActionController::Parameters#to_h` now returns a `Hash` with
unpermitted keys removed. This change is to reflect on a security
concern where some method performed on an `ActionController::Parameters`
may yield a `Hash` object which does not maintain `permitted?` status.
If you would like to get a `Hash` with all the keys intact, duplicate
and mark it as permitted before calling `#to_h`.
params = ActionController::Parameters.new(name: 'Senjougahara Hitagi')
params.to_h # => {}
unsafe_params = params.dup.permit!
unsafe_params.to_h # => {"name"=>"Senjougahara Hitagi"}
safe_params = params.permit(:name)
safe_params.to_h # => {"name"=>"Senjougahara Hitagi"}
This change is consider a stopgap as we cannot chage the code to stop
`ActionController::Parameters` to inherit from
`HashWithIndifferentAccess` in the next minor release.
Also, adding a CHANGELOG entry to mention that
`ActionController::Parameters` will not inheriting from
`HashWithIndifferentAccess` in the next major version.
This method was removed at 210b338db20b1cdd0684f40bd78b52ed16148b99 but it is
used by third party gems to check if a named route was defined. To help on the
upgrade path on 4.2.0 we bring it back and emit a deprecation warning.
Use the Active Support JSON encoder for cookie jars using the `:json` or
`:hybrid` serializer. This allows you to serialize custom Ruby objects into
cookies by defining the `#as_json` hook on such objects.
Fixes#16520.
respond_with (and consequently the class-level respond_to)
are being removed from Rails. Instead of moving it to a 3rd
library, the functionality will be moved to responders gem
(at github.com/plataformatec/responders) which already provides
some responders extensions.
New default: the template digest is automatically included in your ETags.
When you call `fresh_when @post`, the digest for `posts/show.html.erb`
is mixed in so future changes to the HTML will blow HTTP caches for you.
This makes it easy to HTTP-cache many more of your actions.
If you render a different template, you can now pass the `:template`
option to include its digest instead:
fresh_when @post, template: 'widgets/show'
Pass `template: false` to skip the lookup. To turn this off entirely, set:
config.action_controller.etag_with_template_digest = false
This reverts commit 705977620539e2be6548027042f33175ebdc2505, reversing
changes made to dde91e9bf5ab246f0f684b40288b272f4ba9a699.
IT BROKE THE BUILD!!!
Provide the ability to extract the source code of the entire exception stack
trace, not just the frame raising the error. This improves debugging
capability of the error page, especially for framework-related errors.
The latest modification to the code was done in https://github.com/rails/rails/commit/5e3517ea. In Rails 3.2,
`ActionController#rescue_action` was deprecated and `rescue_action_without_handler` is no longer being used.
Previously the generated parser had an intermediate local variable
`result` that really useful if you're building up a stateful object but
Journey always discards the result argument to the reduce functions.
This produces a simpler parser for anybody who actually wants to read
the thing.
Sadly, there's no real performance speedup with this change.
Email does not support relative links since there is no implicit host. Therefore all links inside of emails must be fully qualified URLs. All path helpers are now deprecated. When removed, the error will give early indication to developers to use `*_url` methods instead.
Currently if a developer uses a `*_path` helper, their tests and `mail_view` will not catch the mistake. The only way to see the error is by sending emails in production. Preventing sending out emails with non-working path's is the desired end goal of this PR.
Currently path helpers are mixed-in to controllers (the ActionMailer::Base acts as a controller). All `*_url` and `*_path` helpers are made available through the same module. This PR separates this behavior into two modules so we can extend the `*_path` methods to add a Deprecation to them. Once deprecated we can use this same area to raise a NoMethodError and add an informative message directing the developer to use `*_url` instead.
The module with warnings is only mixed in when a controller returns false from the newly added `supports_relative_path?`.
Paired @sgrif & @schneems
