aboutsummaryrefslogtreecommitdiffstats
path: root/actionpack/test
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #33446 from ptoomey3/nested-respond-toRichard Schneeman2018-07-311-0/+34
|\ | | | | Raises exception when respond_to called multiple times in incompatible way
| * Raises exception when respond_to called multiple times in incompatible wayPatrick Toomey2018-07-301-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nesting respond_to calls can lead to unexpected behavior, so it should be avoided. Currently, the first respond_to format match sets the content-type for the resulting response. But, if a nested respond_to occurs, it is possible to match on a different format. For example: respond_to do |outer_type| outer_type.js do respond_to do |inner_type| inner_type.html { render body: "HTML" } end end end Browsers will often include */* in their Accept headers. In the above example, such a request would result in the outer_type.js match setting the content- type of the response to text/javascript, while the inner_type.html match will cause the actual response to return "HTML". This change tries to minimize potential breakage by only raising an exception if the nested respond_to calls are in conflict with each other. So, something like the following example would not raise an exception: respond_to do |outer_type| outer_type.js do respond_to do |inner_type| inner_type.js { render body: "JS" } end end end While the above is nested, it doesn't affect the content-type of the response.
* | Remove Rubocop's comments from Rails code basebogdanvlviv2018-07-261-4/+0
|/ | | | | | | | | | PR#32381 added Rubocop's comments to some tests files in order to exclude `Performance/RedundantMerge`. Turn off `Performance` cops for tests files via `Exclude` in `.rubocop.yml`. Context https://github.com/rails/rails/pull/32381#discussion_r205212331
* Merge pull request #32381 from q-centrix/update-codeclimate-configsRichard Schneeman2018-07-254-7/+9
|\ | | | | Turn on performance based cops
| * Turn on performance based copsDillon Welch2018-07-234-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use attr_reader/attr_writer instead of methods method is 12% slower Use flat_map over map.flatten(1) flatten is 66% slower Use hash[]= instead of hash.merge! with single arguments merge! is 166% slower See https://github.com/rails/rails/pull/32337 for more conversation
* | Rails guides are now served over httpsPaul McMahon2018-07-241-5/+5
|/ | | | | http links will be redirected to the https version, but still better to just directly link to the https version.
* Add implicit to path conversion to uploaded file (#28676)Aaron Kromer2018-07-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add implicit to path conversion to uploaded file Ruby has a few implicit conversion protocols (e.g. `to_hash`, `to_str`, `to_path`, etc.). These are considered implicit conversion protocols because in certain instances Ruby (MRI core objects) will check if an argument responds to the appropriate protocol and automatically convert it when it does; this is why you can provide a `Pathname` instance into `File.read` without having to explicitly call `to_s`. ```ruby a_file_path = 'some/path/file.ext' File.write a_file_path, 'String Path Content' File.read a_file_path a_pathname = Pathname(a_file_path) File.write core_file, 'Pathname Content' File.read a_file_path core_file = File.new(a_pathname) File.write core_file, 'File Content' File.read core_file tmp_file = Tempfile.new('example') File.write tmp_file, 'Tempfile Content' File.read tmp_file ``` So how does an uploaded file work in such cases? ```ruby tmp_file = Tempfile.new('example') File.write tmp_file, 'Uploaded Content' uploaded_file = ActionDispatch::Http::UploadedFile.new(tempfile: tmp_file) File.read uploaded_file ``` It fails with a `TypeError`: no implicit conversion of ActionDispatch::Http::UploadedFile into String In order to make an uploaded file work it must be explicitly converted to a file path using `path`. ```ruby File.read uploaded_file.path ``` This requires any code that expects path/file like objects to either special case an uploaded file, re-implement the path conversion protocol to use `path`, or forces the developer to explicitly cast uploaded files to paths. This last option can sometimes be difficult to do when such calls are deep within the inner workings of libraries. Since an uploaded file already has a path it makes sense to implement the implicit "path" conversion protocol (just like `File` and `Tempfile`). This change allows uploaded file content to be treated more closely to regular file content, without requiring any special case handling or explicit conversion for common file utilities. * Note uploaded file path delegation in CHANGELOG
* Merge pull request #32410 from yuki24/show-cause-on-debug-view-2Kasper Timm Hansen2018-07-202-15/+80
|\ | | | | Show nested exceptions on the debug view
| * Show nested exceptions on the debug viewYuki Nishijima2018-07-152-15/+80
| |
* | Prevent `RequestEncoder#encode_params` to parse falsey paramsAlireza Bashiri2018-07-201-0/+14
|/ | | | | | | | | | | | | | When a `get` method called with `as: :json` and `params: nil` or `params: false` (explicitly or implicitly) `RequestEncoder#encode_params` converts it into a `null` or `false` value which includes a unexpected `null=` or `false` query string into request URL. From now on `RequestEncoder#encode_params` checks whether `params` is nil or not otherwise returns. Move down `nil` conversion guard Update CHANGELOG.md
* test_should_impose_childless_html_tags_in_html failure with JRubypavel2018-07-151-1/+7
|
* Merge pull request #33341 from Edouard-chin/ec-fix-to-paramRafael França2018-07-121-2/+15
|\ | | | | e4e1b62 broke `to_param` handling:
| * e4e1b62 broke `to_param` handling:Edouard CHIN2018-07-121-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - There was an issue inside controller tests where order params were not respected, the reason was because we were calling `Hash#to_query` which sorts the results lexicographically. 1e4e1b62 fixed that issue by not using `to_query` but instead a utility function provided by rack. - However with the fix came another issue where it's now no longer possible to do this ``` post :foo, params: { user: User.first } # Prior to the patch the controller will receive { "user" => "1" } # Whereas now you get { "user": "#<User: ...>" } ``` The fix in this PR is to modify `Hash#to_query` to sort only when it doesn't contain an array structure that looks something like "bar[]" Ref https://github.com/rails/rails/pull/33341#issuecomment-404039396
* | Enable `Layout/EmptyLinesAroundBlockBody` to reduce review cost in the futureRyuta Kamizono2018-07-122-4/+0
|/ | | | | | | We sometimes ask "✂️ extra blank lines" to a contributor in reviews like https://github.com/rails/rails/pull/33337#discussion_r201509738. It is preferable to deal automatically without depending on manpower.
* Pass along arguments to underlying `get` method in `follow_redirect!` (#33299)Remo Fritzsche2018-07-051-0/+10
| | | | | | | | | | | | | | | | * Allow get arguments for follow_redirect Now all arguments passed to `follow_redirect!` are passed to the underlying `get` method. This for example allows to set custom headers for the redirection request to the server. This is especially useful for setting headers that may, outside of the testing environment, be set automatically on every request, i.e. by a web application firewall. * Allow get arguments for follow_redirect [Remo Fritzsche + Rafael Mendonça França]
* Convert hashes into parameters (#33076)Kevin Sjöberg2018-06-191-0/+21
| | | | | | | | | | | | * Convert hashes into parameters Ensure `ActionController::Parameters#transform_values` and `ActionController::Parameters#transform_values!` converts hashes into parameters. * fixup! Convert hashes into parameters [Rafael Mendonça França + Kevin Sjöberg]
* Merge pull request #33134 from dasch/dasch/extra-cache-controlsEileen M. Uchitelle2018-06-191-0/+20
|\ | | | | Add support for more HTTP cache controls
| * Add support for more HTTP cache controlsDaniel Schierbeck2018-06-131-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From <https://tools.ietf.org/html/rfc5861>: > The stale-if-error HTTP Cache-Control extension allows a cache to > return a stale response when an error -- e.g., a 500 Internal Server > Error, a network segment, or DNS failure -- is encountered, rather > than returning a "hard" error. This improves availability. > > The stale-while-revalidate HTTP Cache-Control extension allows a > cache to immediately return a stale response while it revalidates it > in the background, thereby hiding latency (both in the network and on > the server) from clients. These are useful, fully standardized parts of the HTTP protocol with widespread support among CDN vendors. Supporting them will make it easier to utilize reverse proxies and CDNs from Rails.
* | Add test case for the `|` token in Journey scannervaidehijoshi2018-06-181-0/+6
| | | | | | | | | | | | | | Journey's scanner tokenizes the `|` (:OR) operator when scanning route urls such as `"/:foo|*bar"`. However, the current scanner test does not have any test cases for the `|` operator. This commit adds a test case for this particular token.
* | Fix rubocop violationsbogdanvlviv2018-06-151-1/+1
|/ | | | | | | | https://codeclimate.com/github/rails/rails/issues `bundle exec rubocop -a` Related to e4e1b62007fe40c4277ebc30067837a91bf25967
* Fix bug with eager_load in development environmentDan Jensen2018-06-111-0/+9
| | | | | Modifies the routes simulator to allow for empty RouteSets, which are created when secondary Engines are loaded.
* Use Rack to generate query information under testAaron Patterson2018-06-081-2/+10
| | | | | | | | | | | | | | | | | | | | | | `to_query` sorts parameters before encoding them. This causes a round tripping issue as noted here: https://github.com/rails/rails/issues/23997#issuecomment-328297933 https://github.com/rails/rails/issues/10529#issuecomment-328298109 https://github.com/rails/rails/pull/30558 Unfortunately, that method is being used to generate cache keys, so its results need to be stable: https://github.com/rails/rails/commit/10dec0e65e1f4d87f411b4361045eba86b121be9 However, the test harness is only using `to_query` to encode parameters before sending them to the controller so the "cache key" usecase doesn't apply here. This commit adds a test that demonstrates the round trip problems and changes the serialization strategy to use Rack for encoding the parameters rather than `to_query`.
* Include application/javascript when checking content_typeGabriel Jaldon2018-05-271-0/+5
|
* Fix `CustomCops/AssertNot` to allow it to have failure messageRyuta Kamizono2018-05-135-7/+7
| | | | Follow up of #32605.
* Add support for prefetch-src directiveyuuji.yaginuma2018-05-031-0/+6
| | | | | | | Specification: https://w3c.github.io/webappsec-csp/#directive-prefetch-src This directive can already be used as an experimental feature in Chrome. Ref: https://bugs.chromium.org/p/chromium/issues/detail?id=801561
* Reset CONTENT_LENGTH between test requestsEugene Kenny2018-05-011-0/+8
| | | | | | | If a POST request is followed by a GET request in a controller test, the `rack.input` and `RAW_POST_DATA` headers from the first request will be reset but the `CONTENT_LENGTH` header will leak, leading the request object in the second request to incorrectly believe it has a body.
* Break up Journey's scanner testvaidehijoshi2018-04-241-47/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This breaks up the one megatest for Journey's scanner into multiple test cases, which also provides better output when there is a failure in the scanner. Before: ``` ./bin/test test/journey/route/definition/scanner_test.rb Run options: --seed 778 F Failure: ActionDispatch::Journey::Definition::TestScanner#test_tokens [/Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:57]: --- expected +++ actual @@ -1 +1 @@ -[[:SLASH, "/"], [:LITERAL, "page!!"]] +[[:SLASH, "/"], [:LITERAL, "page!"]] bin/test Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:14 Finished in 0.090899s, 11.0012 runs/s, 44.0049 assertions/s. 1 runs, 4 assertions, 1 failures, 0 errors, 0 skips ``` After: ``` ./bin/test test/journey/route/definition/scanner_test.rb Run options: --seed 2230 ....................F Failure: ActionDispatch::Journey::Definition::TestScanner#test_scanning_/page$ [/Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:58]: Wrong tokens for `/page$`. --- expected +++ actual @@ -1 +1 @@ -[[:SLASH, "/"], [:LITERAL, "page$$"]] +[[:SLASH, "/"], [:LITERAL, "page$"]] bin/test Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:56 F Failure: ActionDispatch::Journey::Definition::TestScanner#test_scanning_/page! [/Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:58]: Wrong tokens for `/page!`. --- expected +++ actual @@ -1 +1 @@ -[[:SLASH, "/"], [:LITERAL, "page!!"]] +[[:SLASH, "/"], [:LITERAL, "page!"]] bin/test Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:56 F Failure: ActionDispatch::Journey::Definition::TestScanner#test_scanning_/page& [/Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:58]: Wrong tokens for `/page&`. --- expected +++ actual @@ -1 +1 @@ -[[:SLASH, "/"], [:LITERAL, "page&&"]] +[[:SLASH, "/"], [:LITERAL, "page&"]] bin/test Users/vaidehijoshi/Code/tilde/rails/actionpack/test/journey/route/definition/scanner_test.rb:56 Finished in 0.126447s, 181.8944 runs/s, 181.8944 assertions/s. 23 runs, 23 assertions, 3 failures, 0 errors, 0 skips ```
* Reset RAW_POST_DATA between test requestsEugene Kenny2018-04-201-0/+8
| | | | | | `RAW_POST_DATA` is derived from the `rack.input` header, which changes with each test request. It needs to be cleared in `scrub_env!`, or all requests within the same test will see the value from the first request.
* Merge pull request #29286 from vinistock/create_missing_exact_template_exceptionRafael Mendonça França2018-04-202-3/+3
|\ | | | | | | Create MissingExactTemplate exception with separate template
| * Create MissingExactTemplate exception with separate templateVinicius Stock2018-04-202-3/+3
| |
* | Merge pull request #23868 from gsamokovarov/debug-exceptions-interceptorsRafael França2018-04-201-0/+24
|\ \ | | | | | | Introduce ActionDispatch::DebugExceptions interceptors
| * | Introduce ActionDispatch::DebugExceptions interceptorsGenadi Samokovarov2018-04-201-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Plugins interacting with the exceptions caught and displayed by ActionDispatch::DebugExceptions currently have to monkey patch it to get the much needed exception for their calculation. With DebugExceptions.register_interceptor, plugin authors can hook into DebugExceptions and process the exception, before being rendered. They can store it into the request and process it on the way back of the middleware chain execution or act on it straight in the interceptor. The interceptors can be play blocks, procs, lambdas or any object that responds to `#call`.
* | | warning: ambiguous first argument; put parentheses or a space even after `/' ↵utilum2018-04-201-1/+1
|/ / | | | | | | operator
* | Merge pull request #32593 from sdhull/fix-strong-params-permit-bangRafael Mendonça França2018-04-191-1/+4
|\ \ | | | | | | | | | Fixes StrongParameters `permit!` to work with nested arrays
| * | Fixes StrongParameters permit! to work with nested arraysSteve Hull2018-04-161-1/+4
| | | | | | | | | | | | | | | `permit!` is intended to mark all instances of `ActionController::Parameters` as permitted, however nested arrays of params were not being marked permitted because the method did shallow iteration. This fixes that by flattening the array before calling `permit!` on all each item.
* | | Replace `assert !` with `assert_not`Daniel Colson2018-04-1914-26/+26
| | | | | | | | | | | | | | | This autocorrects the violations after adding a custom cop in 3305c78dcd.
* | | Pass nonce to CSP policy from outsideAndrew White2018-04-181-21/+72
| | |
* | | Output only one nonce in CSP header per requestAndrey Novikov2018-04-171-5/+23
|/ /
* | Fix rendering a differently-formatted partial after cachingGeorge Claghorn2018-04-133-0/+14
| |
* | Add WebSocket URI support to CSP DSL mappingsStephen Solis2018-04-121-0/+6
| |
* | Add `TestCaseTest#test_request_format_kwarg_doesnt_mutate_params` to masterbogdanvlviv2018-04-101-0/+8
| | | | | | | | | | | | | | | | | | Initially, the test was added to 5-0-stable in #32492 and a bit modified in #32506. This test ensures that request(in tests) doesn't mutate params. It was fixed since v5.1.0.beta1 by 98b8309569a326910a723f521911e54994b112fb and then on 5-0-stable by #32492. This commit adds this test to master branch in order to prevent any regressions.
* | Partially revert 0bfdd1dyuuji.yaginuma2018-04-071-1/+5
| | | | | | | | | | The `Capybara.server=` proc acceptance restored in Capyara 3.0.1. Ref: https://github.com/teamcapybara/capybara/commit/8f115d94e035eca992036f16e50c1dce5f555c97
* | Fix broken `ServerTest` with Capybara 3.0.0yuuji.yaginuma2018-04-061-5/+1
| | | | | | | | | | | | | | It seems that it is no longer possible to specify the value held by `Capybara.server` as sever. Ref: https://github.com/teamcapybara/capybara/commit/ba7674086cbcd3b22d3614011815bc5d483e5960
* | Merge pull request #32441 from composerinteralia/refute-notRafael França2018-04-043-8/+8
|\ \ | | | | | | Add custom RuboCop for `assert_not` over `refute`
| * | Autocorrect `refute` RuboCop violationsDaniel Colson2018-04-033-8/+8
| | | | | | | | | | | | | | | | | | 73e7aab behaved as expected on codeship, failing the build with exactly these RuboCop violations. Hopefully `rubocop -a` will have been enough to get a passing build!
* | | Add #dig to ActionDispatch::Request::Sessionclaudiob2018-04-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Summary The `session` object is not a real Hash but responds to many methods of Hash such as `[]`, `[]`, `fetch`, `has_key?`. Since Ruby 2.3, Hash also supports a `dig` method. This commit adds a `dig` method to `ActionDispatch::Request::Session` with the same behavior as `Hash#dig`. This is useful if you store a hash in your session, such as: ```ruby session[:user] = { id: 1, avatar_url: "http://example.org/nyancat.jpg" } ``` Then you can shorten your code from `session[:user][:avatar_url]` to `session.dig :user, :avatar_url`. ### Other Information I cherry-picked a commit from https://github.com/rails/rails/pull/23864, and modify a bit. The changes are below: * Converts only the first key to a string adjust to the `fetch` method. * Fixes a test case because we cannot use the indifferent access since ee5b621e2f8fde380ea4bc75b0b9d6f98499f511.
* | | Merge pull request #32336 from vincedevendra/allow_mutating_dig_return_valueAaron Patterson2018-04-021-0/+8
|\ \ \ | |/ / |/| | Make mutating params#dig return value mutate underlying params
| * | Make mutating params#dig mutate underlying paramsVince DeVendra2018-03-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When #dig was called on a params object and return either a Hash or an Array, and that value was subsquently mutated, it would not modify the containing params object. That means that the behavior of `params.dig(:a, :b)[:c] = 1` did not match either `params[:a][:b][:c] = 1` nor `hash.dig(:a, :b)[:c] = 1`. Similarly to `ActionController::Parameters#[]`, use `#convert_hashes_to_parameters` to pre-convert values and insert them in the receiving params object prior to returning them.
* | | Merge pull request #32277 from derekprior/dp-deprecate-force-sslGuillermo Iguaran2018-03-302-15/+29
|\ \ \ | |/ / |/| | Deprecate controller level force_ssl
| * | Deprecate controller level force_sslDerek Prior2018-03-302-15/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today there are two common ways for Rails developers to force their applications to communicate over HTTPS: * `config.force_ssl` is a setting in environment configurations that enables the `ActionDispatch::SSL` middleware. With this middleware enabled, all HTTP communication to your application will be redirected to HTTPS. The middleware also takes care of other best practices by setting HSTS headers, upgrading all cookies to secure only, etc. * The `force_ssl` controller method redirects HTTP requests to certain controllers to HTTPS. As a consultant, I've seen many applications with misconfigured HTTPS setups due to developers adding `force_ssl` to `ApplicationController` and not enabling `config.force_ssl`. With this configuration, many application requests can be served over HTTP such as assets, requests that hit mounted engines, etc. In addition, because cookies are not upgraded to secure only in this configuration and HSTS headers are not set, it's possible for cookies that are meant to be secure to be sent over HTTP. The confusion between these two methods of forcing HTTPS is compounded by the fact that they share an identical name. This makes finding documentation on the "right" method confusing. HTTPS throughout is quickly becomming table stakes for all web sites. Sites are expected to operate over HTTPS for all communication, sensitive or otherwise. Let's encourage use of the broader-reaching `ActionDispatch::SSL` middleware and elminate this source of user confusion. If, for some reason, applications need to expose certain endpoints over HTTP they can do so by properly configuring `config.ssl_options`.
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-30 08:15:38 +0000