| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `#csrf_meta_tags` and `#token_tag` Action View helper methods are
expecting the class in which are included to explicitly define the
method `#protect_against_forgery?` or else they will fail with
`NoMethodError`.
This is a problem if you want to use Action View outside of Rails
applications. For example, in #34788 I used the `#button_to` helper
inside of the error pages templates that have a custom
`ActionView::Base` subclass, which did not defined
`#protect_against_forgery?` and trying to call the button failed.
I had to dig inside of Action View to find-out what's was going on. I
think we should either set a default method implementation in the
helpers or check for the method definition, but don't explicitly require
the presence of `#protect_against_forgery?` in every `ActionViews::Base`
subclass as the errors are hard to figure out.
|
|
|
|
|
|
|
|
| |
The url_for method is now extracting the path_only option in order to determine if polymorphic_path or polymorphic_url should be called.
If the path_only option is not set it will be set to true unless the host option is set. This behaviour is the same as when a Hash or Params object is passed.
To support this unifying the code responsible for setting this default value has been extracted into a private method
|
|\
| |
| | |
Remove deprecated catch-all route in the AV tests
|
| |
| |
| |
| |
| |
| |
| |
| | |
This commit removes a deprecated catch-all route in the AV tests. It
defines and includes the necessary routes for each test such that we
don't need the catch-all anymore.
This also helps push us toward #33970
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`.
```ruby
# frozen_string_literal: true
require "bundler/inline"
gemfile(true) do
source "https://rubygems.org"
gem "benchmark-ips"
end
Benchmark.ips do |x|
x.report('+@') { +"" }
x.report('dup') { "".dup }
x.compare!
end
```
```
$ ruby -v benchmark.rb
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
Warming up --------------------------------------
+@ 282.289k i/100ms
dup 187.638k i/100ms
Calculating -------------------------------------
+@ 6.775M (± 3.6%) i/s - 33.875M in 5.006253s
dup 3.320M (± 2.2%) i/s - 16.700M in 5.032125s
Comparison:
+@: 6775299.3 i/s
dup: 3320400.7 i/s - 2.04x slower
```
|
|
|
|
|
|
|
|
|
| |
`button_to` was throwing exception when invoked with `params` hash that
contains symbol and string keys. The reason for the exception was that
`to_form_params` was comparing the given symbol and string keys.
The issue is fixed by turning all keys to strings inside
`to_form_params` before comparing them.
|
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
| |
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
|\
| |
| |
| | |
Enforce frozen string in Rubocop
|
| | |
|
|\ \
| |/
|/|
| | |
Make ActiveSupport frozen-string-literal friendly.
|
| |
| |
| |
| | |
Plus a couple of related ActionPack patches.
|
|/ |
|
| |
|
|
|
|
| |
see: https://bugs.ruby-lang.org/issues/6696
|
|\
| |
| | |
`sort_query_string_params` method is no more used
|
| |
| |
| |
| |
| | |
- This method was added in this commit https://github.com/rails/rails/commit/33258d713a4bc20b71e92fd656c923a7b189cd33
- The last caller got removed there https://github.com/rails/rails/commit/0b6ce3422370647cad3e91263a291f69b313d65b
|
|/
|
|
|
|
| |
- `check_parameters` kwargs was added to the `current_page?` method, the implementation was assuming only hashes responds to `delete`. This was causing issues when `current_page?` was called with a Active Model object
- ref https://github.com/rails/rails/pull/27549
- Fixes #28846
|
|
|
|
|
| |
Since this protection is now in Parameters we can use it instead of
reimplementing again.
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|\
| |
| | |
Add "check_parameters" option to "current_page?"
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
For "http://www.example.com/shop/checkout?order=desc&page=1"
current_page?('http://www.example.com/shop/checkout')
=> true
current_page?(
'http://www.example.com/shop/checkout',
check_parameters: true
)
=> false
|
|/
|
|
|
|
|
|
|
| |
```
% git grep -n permited
actionview/test/template/url_helper_test.rb:238: def test_button_to_with_permited_strong_params
actionview/test/template/url_helper_test.rb:245: def test_button_to_with_unpermited_strong_params
activerecord/test/cases/relations_test.rb:1620: def test_update_on_relation_passing_active_record_object_is_not_permited
```
|
| |
|
|\
| |
| |
| | |
Convert ActionController::Parameters to a hash in button_to
|
|/
|
|
|
|
|
|
|
|
|
| |
Before, an error would be raised saying that the method `to_param` was
undefined on the instance of `ActionController::Parameters`. Now, we are
checking to see if the `params` object being passed to `button_to`
responds to the `permitted?` method, and if so, we will call `to_h` on it. If it
does not respond to `permitted?`, then the `params` will remain
unchanged.
[Jon Moss, Rafael Mendonça França]
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
| |
https://github.com/rails/rails/issues/19472
|
|
|
|
|
|
| |
View test
Follow up to #23980.
|
|
|
|
|
|
| |
In e6e0579defcfcf94ef1c4c1c7659f374a5335cdb the `params` option was added to the `button_to` helper. However, the patch doesn't support nested hashes so `{a: {b: 'c'}}` for example gets turned into a hidden form input with the name 'a' and the value being the string representation of the `{b: 'c'}` nested hash.
Since Rails supports nested hashes everywhere else (and even in the URL params of link_to and button_to), I believe this to be a bug/unfinished feature.
|
|
|
|
|
|
| |
of html_safe in favour of raw() in AV helpers.
Also changed usage of html_safe to make use of raw() instead so that the intended behaviour is verified with raw()
|
| |
|
| |
|
|\
| |
| | |
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.)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`link_to :back` creates a link to whatever was
passed in via the referer header. If an attacker
can alter the referer header, that would create
a cross-site scripting vulnerability on every
page that uses `link_to :back`
This commit restricts the back URL to valid
non-javascript URLs.
https://github.com/rails/rails/issues/14444
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `url_for` methods in `actionpack` and `actionview`
now make a copy of the provided options
before generating polymorphic paths or URLs.
The bug in the previous behavior
is most noticeable in a case like:
url_options = [:new, :post, param: 'value']
if current_page?(url_options)
css_class = "active"
end
link_to "New Post", url_options, class: css_class
|
| |
|
| |
|
|
|
|
|
|
|
| |
Prompted by:
https://github.com/rails/rails/commit/e38dd7bfa4360e241eadf0cf44abdf86ea33a393#commitcomment-11011496
/cc @kuldeepaggarwal
|
|
|
|
|
|
|
| |
This illustrates the purpose of the block for `link_to_if` and
`link_to_unless` helper methods.
It should help to prevent further mistakes like #19844.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stevenspiel/link_to_if_block_helper_addition"
This reverts commit d459b001b43d25053e7982e96eb8383538a6e358, reversing
changes made to 4d4950fae9e2a6970b5f1793aadc56a0b44e28a3.
:sweat:
The block is not supposed to be passed to `link_to`. It's used for a
customized behavior of the `condtion = false` case. The docs
illustrate that like so:
```
<%=
link_to_if(@current_user.nil?, "Login", { controller: "sessions", action: "new" }) do
link_to(@current_user.login, { controller: "accounts", action: "show", id: @current_user })
end
%>
```
|
|
|
|
| |
Update url_helper.rb
|