| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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.
|
| | |
|
|\ \
| | |
| | | |
Don't catch all NameError to reraise as ActionController::RoutingError
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Follow-up to PR #19977, which helpfully added the redirection path to the error message of assert_response if response is a redirection, but which removed the response code, obscuring the type of redirect.
This PR:
- brings back the response code in the error message,
- updates the tests so the new messages can be tested,
- and adds test cases for the change.
|
|\ \
| | |
| | |
| | |
| | | |
prathamesh-sonpatki/use-assert-over-assert-predicate
Use assert over assert_predicate in assert_response
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- `assert_predicate` appends its own error message at the end of message
generated by `assert_response` and because of that the error message
displays the whole `response` object.
- For eg.
Expected response to be a <success>, but was a redirect to <http://test.host/posts>.
Expected #<ActionDispatch::TestResponse:0x007fb1cc1cf6f8....(lambda)>}>> to be successful?.
- Complete message can be found here -
https://gist.github.com/prathamesh-sonpatki/055afb74b66108e71ded#file-gistfile1-txt-L19.
- After this change the message from `assert_predicate` won't be
displayed and only message generated by `assert_response` will be shown
as follows:
Expected response to be a <success>, but was a redirect to <http://test.host/posts>
|
|\ \ \
| | | |
| | | | |
Rails API: Ability to return error responses in json format also in development
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I did this change but it is affecting how the request params end up
after being processed by the router.
To be in the safe side, I just take the format from the extension in the
URL when is not present in those params and it's being used only for the
`Request#formats` method
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
```
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| |/ /
|/| | |
Test against the real value of tld_length unless explicitly set
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
There were two places where the tld_length default
was hard-coded to 1, both overriding the real default
value of ActionDispatch::Http::URL.tld_length in this
set of tests.
This commit removes both of those, relying on the
actual value of ActionDispatch::Http::URL.tld_length,
unless it's specifically overridden.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
:redirect
- If the assert_response is checking for any non-redirect response like
:success and actual response is :redirect then, the error message displayed
was -
Expected response to be a <success>, but was <302>
- This commit adds the redirect path to the error message of
assert_response if the response is :redirect.
So above message is changed to -
Expected response to be a <success>, but was a redirect to <http://test.host/posts/lol>
|
|\ \
| | |
| | | |
Brush up errors of `ActionDispatch::Routing::Mapper#mount`
|
| | |
| | |
| | |
| | |
| | |
| | | |
* Integrate to raise `ArgumentError`
* Detailed error message when `path` is not defined
* Add a test case, invalid rack app is passed
|
|\ \ \
| | | |
| | | | |
In url_for, never append ? when the query string is empty anyway.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It used to behave like this:
url_for(controller: 'x', action: 'y', q: {})
# -> "/x/y?"
We previously avoided empty query strings in most cases by removing
nil values, then checking whether params was empty. But as you can
see above, even non-empty params can yield an empty query string. So
I changed the code to just directly check whether the query string
ended up empty.
(To make everything more consistent, the "removing nil values"
functionality should probably move to ActionPack's Hash#to_query, the
place where empty hashes and arrays get removed. However, this would
change a lot more behavior.)
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Add option to verify Origin header in CSRF checks
[Jeremy Daer + Rafael Mendonça França]
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Add text template for source code
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
When a request is made with AJAX and an error occurs, Rails will render
a text-template for the exception instead of the HTML error page
(#11960).
The `.text.erb` variant of the `_source` template is currently missing,
causing HTML to be rendered in the response. This commit adds the text
template.
To keep the page scannable we only only show the first three source
extracts.
Related to #14745.
Before:
```
~/testing-exceptions ᐅ curl 'http://localhost:3000/' -H
'X-Requested-With: XMLHttpRequest'
RuntimeError in PostsController#index
<div class="source " id="frame-source-0">
<div class="info">
Extracted source (around line <strong>#3</strong>):
</div>
<div class="data">
<table cellpadding="0" cellspacing="0" class="lines">
<tr>
```
After:
```
~/testing-exceptions ᐅ curl 'http://localhost:3000/' -H
'X-Requested-With: XMLHttpRequest'
RuntimeError in PostsController#index
Extracted source (around line #3):
*3 raise
```
|
|\ \ \ \ \ \
| |_|_|_|/ /
|/| | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The initial attempt was to remove the method at all in
https://github.com/sergey-alekseev/rails/commit/4926aa68c98673e7be88a2d2b57d72dc490bc71c.
The method overrides Rack's `#form_data?`
https://github.com/rack/rack/blob/6f8808d4201e68e4bd780441b3b7bb3ee6d1f43e/lib/rack/request.rb#L172-L184.
Which may have some incorrect implementation actually. `type.nil?` isn't possible I suppose. I'll check.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This code was added for migration from Rails 3.1 to upper,
now we are developing Rails 5.
|
| |_|/ / /
|/| | | | |
|
| | | | | |
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This solves:
```
Expected /Completed 200 OK in [\d]ms/ to match "Completed 200 OK in 943ms".
```
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | | |
Add test for parsing application/vnd.api+json
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
This reverts commit 9f93a5efbba3e1cbf0bfa700a17ec8d1ef60d7c6.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
rather than an action name and *args. The *args were not being used in regular
applications outside tests. This causes a backwards compatibility
issue, but reduces array allocations for most users.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For ActionController::Base we write the cookies in a middleware if it
was not yet committed no matter if the response was committed or not. [1]
For ActionController::Live we write the cookies before the response is
committed. [2]
We already mimic ActionController::Live in
ActionController::TestCase but we don't mimic the ActionController::Base
behavior because we were checking if the response was committed before
writing the cookies.
Now we are matching the behavior of the middleware and writing the
cookies if it was not written before.
[1]: https://github.com/rails/rails/blob/80c6b901d4d87cee610ab0a438ff6e3c6bf118d1/actionpack/lib/action_dispatch/middleware/cookies.rb#L599-L604
[2]: https://github.com/rails/rails/blob/80c6b901d4d87cee610ab0a438ff6e3c6bf118d1/actionpack/lib/action_controller/metal/live.rb#L218-L223
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|