| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Two implemented but undocumented features are to help indicate that cache is fresh for 3 hours, and it may continue to be served stale for up to an additional 60 seconds to parallel requests for the same resource or up to 5 minutes while errors are being returned back while the initial synchronous revalidation is attempted.
|
|
|
|
|
|
|
|
|
|
|
| |
When running with code triage and derailed benchmarks and focusing on this file:
Before
16199 /Users/rschneeman/Documents/projects/rails/actionpack/lib/action_controller/metal/strong_parameters.r
After
2280 /Users/rschneeman/Documents/projects/rails/actionpack/lib/action_controller/metal/strong_parameters.rb
|
| |
|
|\
| |
| | |
Finish converting whitelist and blacklist references
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Call block to #redirect_to in controller context
The documentation for ActionController::Redirecting states that a Proc
argument "will be executed in the controller's context." However,
unless #instance_eval is used (removed in 6b3ad0ca), that statement is
false for procs defined outside of the controller instance.
This commit restores the documented behavior.
Fixes #33731.
* Move test proc into a constant in another class
Per @rafaelfranca's suggestion.
[Steven Peckins + Rafael Mendonça França]
|
|/
|
|
|
| |
This updates the `respond_to` method to be code formatted rather than
plain text (as it refers to the method)
|
|
|
|
|
|
|
|
|
|
| |
The regexp was introduced in 186ac4cdaa911a9af659a29f2179a19b99dea13b,
and looks cosmetic. While they should be functionally identical in
theory, in practice, case insensitive (but preserving) filesystems can
give results that are differently-cased from the pattern we supplied.
I don't know how to force the filesystem to do the surprising thing,
even when running in an environment that _could_, so no new test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Layout/TrailingWhitespace
```
actionpack/lib/action_controller/metal/request_forgery_protection.rb:49:4:
C: Layout/TrailingWhitespace: Trailing whitespace detected.
#
^
```
Related to c3787494eda
- Performance/StartWith
```
tasks/release.rb:108:44: C: Performance/StartWith:
Use String#start_with? instead of a regex match anchored to the beginning of the string.
header += "* No changes.\n\n\n" if current_contents =~ /\A##/
```
|
|\
| |
| | |
fixes #27157 CSRF protection documentation
|
| |
| |
| |
| |
| | |
* removed reference to GET requests where it applies also to other HTTP verbs
* updated documentation to try and better explain how CSRF protection
works with XHR, and the potential exposure with CORS
|
|\ \
| | |
| | | |
Default content type for `head` is `text/html`
|
| | |
| | |
| | |
| | | |
Otherwise Mime::NullType will be returned as the `Content-Type` header.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | | |
Turn on performance based cops
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
|/ / /
| | |
| | |
| | |
| | | |
http links will be redirected to the https version, but still better to
just directly link to the https version.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Complete renderer documentation
Fixes #28484
|
| | |
| | |
| | |
| | |
| | |
| | | |
[ci skip]
Follow up #33401, 5491f8115711d8b34d52f8ba5e52ba39a49b08fe.
|
| | |
| | |
| | |
| | | |
Follow up to 9f152a606
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- 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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`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`.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Benchmark:
```ruby
require 'benchmark'
require 'benchmark/ips'
require 'securerandom'
def xor_byte_strings(s1, s2) # :doc:
s2_bytes = s2.bytes
s1.each_byte.with_index { |c1, i| s2_bytes[i] ^= c1 }
s2_bytes.pack("C*")
end
def xor_byte_strings_new(s1, s2) # :doc:
s2 = s2.dup
size = s1.bytesize
i = 0
while i < size
s2.setbyte(i, s1.getbyte(i) ^ s2.getbyte(i))
i += 1
end
s2
end
s1 = SecureRandom.random_bytes(32)
s2 = SecureRandom.random_bytes(32)
Benchmark.ips do |x|
x.report("current"){xor_byte_strings(s1, s2)}
x.report("new"){xor_byte_strings_new(s1, s2)}
x.compare!
end
100000.times do |i|
s3 = SecureRandom.random_bytes(32)
s4 = SecureRandom.random_bytes(32)
raise unless xor_byte_strings(s3, s4) == xor_byte_strings_new(s3, s4)
end
```
Results on ruby 2.5.1:
```
Warming up --------------------------------------
current 6.519k i/100ms
new 10.508k i/100ms
Calculating -------------------------------------
current 84.723k (_ 0.4%) i/s - 423.735k in 5.001456s
new 145.871k (_ 0.3%) i/s - 735.560k in 5.042606s
Comparison:
new: 145870.6 i/s
current: 84723.4 i/s - 1.72x slower
```
|
| | |
| | |
| | |
| | |
| | | |
Make it clear that the return value is converted to an
instance of ActionController::Parameters if possible
|
|\ \ \
| | | |
| | | | |
Reset CONTENT_LENGTH between test requests
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|/ / /
| | |
| | |
| | | |
The example code is meant to be a string.
|
| | |
| | |
| | |
| | |
| | |
| | | |
`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.
|
|\ \ \
| | | |
| | | |
| | | | |
Create MissingExactTemplate exception with separate template
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
`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.
|
|\ \ \ \
| | | | |
| | | | | |
Include default headers by default in API mode
|
| | | | |
| | | | |
| | | | |
| | | | | |
ActionDispatch's default headers are now moved into their own module that are by default included in both Base and API. This allows API-mode applications to take advantage of the default security headers, as well as providing an easy way to add more.
|
|/ / / / |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Make mutating params#dig return value mutate underlying params
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`.
|
| | | |
| | | |
| | | |
| | | | |
Since Rails 6 requires Ruby 2.4.1+.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
If the app has the CSP disabled globally allow a controller action
to enable the policy for that request.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
e.g:
class LegacyPagesController < ApplicationController
content_security_policy false, only: :index
end
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Because the UJS library creates a script tag to process responses it
normally requires the script-src attribute of the content security
policy to include 'unsafe-inline'.
To work around this we generate a per-request nonce value that is
embedded in a meta tag in a similar fashion to how CSRF protection
embeds its token in a meta tag. The UJS library can then read the
nonce value and set it on the dynamically generated script tag to
enable it to execute without needing 'unsafe-inline' enabled.
Nonce generation isn't 100% safe - if your script tag is including
user generated content in someway then it may be possible to exploit
an XSS vulnerability which can take advantage of the nonce. It is
however an improvement on a blanket permission for inline scripts.
It is also possible to use the nonce within your own script tags by
using `nonce: true` to set the nonce value on the tag, e.g
<%= javascript_tag nonce: true do %>
alert('Hello, World!');
<% end %>
Fixes #31689.
|