| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
| |
This offenced code is introduced from forward ported #36196, since looks
like 6-0-stable branch isn't checked by CodeClimate.
|
| |
|
|
|
|
|
|
|
| |
Hide malformed parameters from error page
Accidentally merged this to 6-0-stable so forward porting it to master
here instead.
|
| |
|
|
|
|
|
|
|
| |
Because controllers' `perform_caching` config is `true` by default, it
means we actually enable the caching in all those tests implicitly (and
it works). Which also means we can avoid repeatedly declaring that and
just specify it once in the setup method (just for declaration).
|
| |
|
|\
| |
| | |
Include Caching module for ActionController::API
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently ActionController::API doesn't include Caching module, so it
can't perform caching. And even if users include it later manually, it
won't inherit application's default cache store for action_controllers.
So the only way to solve this issue is to include Caching module in
ActionController::API, too.
This closes #35602
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we were calling the `take_failed_screenshot` method in an
`after_teardown` hook. However, this means that other teardown hooks
have to be executed before we take the screenshot. Since there can be
dynamic updates to the page after the assertion fails and before we
take a screenshot, it seems desirable to minimize that gap as much as
possible. Taking the screenshot in a `before_teardown` rather than an
`after_teardown` helps with that, and has a side benefit of allowing
us to remove the nested `ensure` commented on here:
https://github.com/rails/rails/pull/34411#discussion_r232819478
|
| | |
|
|\ \
| | |
| | | |
handle long or duplicated screenshot filenames
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actionable errors let's you dispatch actions from Rails' error pages. This
can help you save time if you have a clear action for the resolution of
common development errors.
The de-facto example are pending migrations. Every time pending migrations
are found, a middleware raises an error. With actionable errors, you can
run the migrations right from the error page. Other examples include Rails
plugins that need to run a rake task to setup themselves. They can now
raise actionable errors to run the setup straight from the error pages.
Here is how to define an actionable error:
```ruby
class PendingMigrationError < MigrationError #:nodoc:
include ActiveSupport::ActionableError
action "Run pending migrations" do
ActiveRecord::Tasks::DatabaseTasks.migrate
end
end
```
To make an error actionable, include the `ActiveSupport::ActionableError`
module and invoke the `action` class macro to define the action. An action
needs a name and a procedure to execute. The name is shown as the name of a
button on the error pages. Once clicked, it will invoke the given
procedure.
|
|\
| |
| | |
mounted routes with non-word characters
|
| | |
|
| |
| |
| |
| |
| |
| | |
Unless I'm missing some undocumented use case, these modules aren't
needed in `StrongParameters` anymore since 8e221127ab. Also, all
actionpack tests are passing without them.
|
|\ \
| | |
| | | |
Remove lock from method model
|
| | | |
|
|\ \ \
| | | |
| | | | |
Simplify and fasten NamedRouteCollection#define_url_helper
|
| | |/
| |/| |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
This change adds a `named_captures` method to
`ActionDispatch::Journey::Path::MatchData` in order to emulate a similar
method present on `Regex`'s `MatchData` present in Ruby core.
This method can be useful for introspection of routes without the need
to use `zip` while testing or developing in Rails core.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Deduplicate strings held by the router
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Make Resolver#find_all_anywhere equivalent to #find_all
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, when using `render file:`, it was possible to render files
not only at an absolute path or relative to the current directory, but
relative to ANY view paths. This was probably done for absolutely
maximum compatibility when addressing CVE-2016-0752, but I think is
unlikely to be used in practice.
Tihs commit removes the ability to `render file:` with a path relative
to a non-fallback view path.
Make FallbackResolver.new private
To ensure nobody is making FallbackResolvers other than "/" and "".
Make reject_files_external_... no-op for fallbacks
Because there are only two values used for path: "" and "/", and
File.join("", "") == File.join("/", "") == "/", this method was only
testing that the absolute paths started at "/" (which of course all do).
This commit doesn't change any behaviour, but it makes it explicit that
the FallbackFileSystemResolver works this way.
Remove outside_app_allowed argument
Deprecate find_all_anywhere
This is now equivalent to find_all
Remove outside_app argument
Deprecate find_file for find
Both LookupContext#find_file and PathSet#find_file are now equivalent to
their respective #find methods.
|
| | |
| | |
| | |
| | | |
readability. PR after #24405
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Honor shallow: false on nested resources
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously there was no way to place a non-shallow resource inside a parent
with `shallow: true` set. Now you can set `shallow: false` on a nested child
resource to generate normal (non-shallow) routes for it.
Fixes #23890.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Fix typo in the value of ENCRYPTED_SIGNED_COOKIE_SALT constant
* Fix value of cookie in with authenticated encryption flag off in tests
[Emil Shakirov + Ryuta Kamizono]
|
| | |
| | |
| | |
| | |
| | |
| | | |
* use backticks instead of `+`
* and more (e.g. missed replacing `Array#excluding` and
`Enumerable#excluding` in b89a3e7e638a50c648a17d09c48b49b707e1d90d)
|
|\ \ \
| | | |
| | | | |
RFC: Introduce Template::File
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous behaviour of render file: was essentially the same as
render template:, except that templates can be specified as an absolute
path on the filesystem.
This makes sense for historic reasons, but now render file: is almost
exclusively used to render raw files (not .erb) like public/404.html. In
addition to complicating the code in template/resolver.rb, I think the
current behaviour is surprising to developers.
This commit deprecates the existing "lookup a template from anywhere"
behaviour and replaces it with "render this file exactly as it is on
disk". Handlers will no longer be used (it will render the same as if
the :raw handler was used), but formats (.html, .xml, etc) will still be
detected (and will default to :plain).
The existing render file: behaviour was the path through which Rails
apps were vulnerable in the recent CVE-2019-5418. Although the
vulnerability has been patched in a fully backwards-compatible way, I
think it's a strong hint that we should drop the existing
previously-vulnerable behaviour if it isn't a benefit to developers.
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | | |
.all isn't a valid file extension, so it shouldn't used as a symbol.
This also makes Mime::ALL better match how */* is parsed from an Accept
header.
|
|\ \ \
| | | |
| | | | |
Prohibit sneaky custom params from being drawn (Fix #30467)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
After this change it's not possible anymore to configure routes
like this:
routes.draw do
resources :users, param: "name/:sneaky"
end
Fixes #30467.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- https://github.com/rails/rails/pull/35604 introduced a vulnerability fix
to raise an error in case the `HTTP_ACCEPT` headers contains malformated
mime type.
This will cause applications to throw a 500 if a User Agent sends an
invalid header.
This PR adds the `InvalidMimeType` in the default `rescue_responses` from
the ExceptionWrapper and will return a 406. I looked up the HTTP/1.1
RFC and it doesn't stand what should be returned when the UA
sends malformated mime type. Decided to get 406 as it seemed to be the
status the better suited for this.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Don't override @set_cookies on CookieJar#update_cookies_from_jar'
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When building the cookie_jar for the current test request.
It was possible for this method to override keys currently being set on the test itself.
In situations such as when making two requests mixing creating the cookie on the test and the controller.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This test was trying to set the exception_app in the wrapper proxy
instead in the middleware itself.
|
|\ \ \ \
| | | | |
| | | | | |
Update regular expression for checking valid MIME type
|