| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Prevent ActionController::Parameters in url_for
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
If you're not familiar with how the `Referer` header works, you likely
won't understand why you need to provide a fallback or under what
circumstances it would be used.
Hopefully this clarifies things a bit.
|
| |
| |
| |
| |
| |
| |
| |
| | |
When calling `to_h` on an `ActionController::Parameters` instance it would
`deep_dup` its internal parameters.
This inadvertently called `dup` on a passed Active Record model which would
create new models. Fix by only dupping Ruby's Arrays and Hashes.
|
| |
| |
| |
| |
| |
| |
| | |
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`.
|
|\ \
| | |
| | |
| | | |
Handle tab in token authentication header.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The HTTP spec allows for LWS to precede the header content, which
could include multiple SP and HT characters. Update the regex used to
match the Token authorization header to account for this, instead of
matching on a single SP.
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html and
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html for the relevant
parts of the specification.
|
| |/
|/|
| |
| |
| |
| |
| | |
This makes these two methods to be more inline with the previous
behavior of Parameters as Parameters used to be inherited from HWIA.
Fixes #21391
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All of our tests were testing the `ActionController::Live` behavior in a
standalone environment, without going through the router or behaving
like a real application.
This resulted in `ActionController::Live` throwing the exception
`undefined method 'request' for #<ActionDispatch::Request:0x00000003ad1148>`
because `make_response!` was expecting a response instead of a request.
The expectation of a response came from `set_response!` in non-router
tests setting the response and passing it to `make_response!`. In the
case of an application we would hit `serve` in `RouteSet` first which
would send us to `make_response!` with a request sent instead of a
response.
The changes here remove `set_response!` so `make_response!` always
receives a request.
Thanks to KalabiYau for help with the investigation and solution.
Fixes #22524
[Eileen M. Uchitelle & KalabiYau]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
|\ \
| | |
| | | |
Add missing require to strong_parameters.rb
|
| | |
| | |
| | |
| | |
| | | |
The file [references Rack::Test here](https://github.com/rails/rails/blame/master/actionpack/lib/action_controller/metal/strong_parameters.rb#L671)
so it's better off requiring 'rack/test' in the first place.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want to get rid of the `Live::Response` so we are consolidating methods
from `Live::Response` and `Response` by merging them together.
This adds an `#empty` method to the request so we don't need to
hard-code the empty array each time we call an empty
`ActionDispatch::Request`.
The work here is a continuation on combining controller and integration
test code bases into one.
|
|\ \
| | |
| | |
| | |
| | | |
Add option to verify Origin header in CSRF checks
[Jeremy Daer + Rafael Mendonça França]
|
| | | |
|
|/ / |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`dispatch` sets the request and response on the controller for us
automatically, so the test harness doesn't need to know the internals of
how request / response is set.
Conflicts:
actionpack/lib/action_controller/test_case.rb
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Delete needless `require 'active_support/deprecation'`
|
| | |
| | |
| | |
| | |
| | | |
When `require 'active_support/rails'`, 'active_support/deprecation'
is automatically loaded.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Prior to this change, given a route:
# config/routes.rb
get ':a' => "foo#bar"
If one pointed to http://example.com/%BE (param `a` has invalid encoding),
a `BadRequest` would be raised with the following non-informative message:
ActionController::BadRequest
From now on the message displayed is:
Invalid parameter encoding: hi => "\xBE"
Fixes #21923.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Rails 4.x and earlier didn't support `Mime::Type[:FOO]`, so libraries
that support multiple Rails versions would've had to feature-detect
whether to use `Mime::Type[:FOO]` or `Mime::FOO`.
`Mime[:foo]` has been around for ages to look up registered MIME types
by symbol / extension, though, so libraries and plugins can safely
switch to that without breaking backward- or forward-compatibility.
Note: `Mime::ALL` isn't a real MIME type and isn't registered for lookup
by type or extension, so it's not available as `Mime[:all]`. We use it
internally as a wildcard for `respond_to` negotiation. If you use this
internal constant, continue to reference it with `Mime::ALL`.
Ref. efc6dd550ee49e7e443f9d72785caa0f240def53
|
| |
| |
| |
| |
| |
| |
| | |
Just a slight refactor that delegates file sending to the response
object. This gives us the advantage that if a webserver (in the future)
provides a response object that knows how to do accelerated file
serving, it can implement this method.
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
* add `end` to end of class definition
* add a blank line between explanation and example code
|
| | |
| | |
| | |
| | |
| | | |
the caller of `handle_conditional_get!` checks the committed state of
the response, so we don't need to in the subclass.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I want to move the header hash to the super request object in order to
consolidate behavior. We should be switching out buffering strategies
rather than header strategies since things like "mutating headers after
send" is an error in both cases (buffering vs streaming).
|
| | |
| | |
| | |
| | |
| | | |
again, since we are going through the test harness, all this is done
for us.
|
| | |
| | |
| | |
| | |
| | | |
Since we just go through the normal test harness that sets up a request
for us, we don't need to do this anymore.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm making this change so that I can construct response objects that
*don't* have the default headers applied. For example, I would like to
construct a response object from the return value of a controller.
If you need to construct a response object with the default headers,
then please use the alternate constructor:
`ActionDispatch::Response.create`
|
| | | |
|
| | |
| | |
| | | |
As we all know that Accessing mime types via constants is deprecated. Now, we are using `Mime::Type[:JSON]` instead of `Mime::JSON`
|
| | |
| | |
| | |
| | |
| | | |
We can know whether or not there is a content type object, and just exit
early. There is no need to `try` so hard.
|
| | | |
|
|/ /
| |
| |
| |
| | |
We should be asking the mime type method for the mime objects rather
than via const lookup
|
| | |
|
| |
| |
| |
| | |
this commit removes some direct access to `env`.
|
| |
| |
| |
| |
| | |
this means the reader doesn't need to lock, but does have the added cost
of a new object created for every controller
|
| | |
|
| |
| |
| |
| |
| | |
The controller class is shared among threads, so we need to lock when
allocating the Renderer.
|
| |
| |
| |
| |
| | |
AC::Parameters does not inherit from HashWithIndifferentAccess
since #20868 by @sikachu
|
| |
| |
| |
| |
| | |
everything above metal really doesn't care about setting the content
type, so lets rearrange these methods to be in metal.
|
| |
| |
| |
| |
| |
| |
| | |
_set_content_type only does something when there is a request object,
otherwise the return value of _get_content_type is always ignored. This
commit moves everything to the module that has access to the request
object so we'll never to_s unless there is a reason
|
| |
| |
| |
| |
| | |
in the future I would like to make the header hash read only (or at
least remove guarantees that mutations will do anything).
|
| |
| |
| |
| | |
action_controller_overview file Rails' -> Rails" [ci skip]
|
| | |
|