| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A HTTP feature policy is Yet Another HTTP header for instructing the
browser about which features the application intends to make use of and
to lock down access to others. This is a new security mechanism that
ensures that should an application become compromised or a third party
attempts an unexpected action, the browser will override it and maintain
the intended UX.
WICG specification: https://wicg.github.io/feature-policy/
The end result is a HTTP header that looks like the following:
```
Feature-Policy: geolocation 'none'; autoplay https://example.com
```
This will prevent the browser from using geolocation and only allow
autoplay on `https://example.com`. Full feature list can be found over
in the WICG repository[1].
As of today Chrome and Safari have public support[2] for this
functionality with Firefox working on support[3] and Edge still pending
acceptance of the suggestion[4].
#### Examples
Using an initializer
```rb
# config/initializers/feature_policy.rb
Rails.application.config.feature_policy do |f|
f.geolocation :none
f.camera :none
f.payment "https://secure.example.com"
f.fullscreen :self
end
```
In a controller
```rb
class SampleController < ApplicationController
def index
feature_policy do |f|
f.geolocation "https://example.com"
end
end
end
```
Some of you might realise that the HTTP feature policy looks pretty
close to that of a Content Security Policy; and you're right. So much so
that I used the Content Security Policy DSL from #31162 as the starting
point for this change.
This change *doesn't* introduce support for defining a feature policy on
an iframe and this has been intentionally done to split the HTTP header
and the HTML element (`iframe`) support. If this is successful, I'll
look to add that on it's own.
Full documentation on HTTP feature policies can be found at
https://wicg.github.io/feature-policy/. Google have also published[5] a
great in-depth write up of this functionality.
[1]: https://github.com/WICG/feature-policy/blob/master/features.md
[2]: https://www.chromestatus.com/feature/5694225681219584
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801
[4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy
[5]: https://developers.google.com/web/updates/2018/06/feature-policy
|
|
|
|
| |
The example code is meant to be a string.
|
|
|
|
| |
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.
|
|
|
|
| |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
|
|
|
|
| |
This basically reverts e9fca7668b9eba82bcc832cb0061459703368397, d08da958b9ae17d4bbe4c9d7db497ece2450db5f,
d1fe1dcf8ab1c0210a37c2a78c1ee52cf199a66d, and 68eaf7b4d5f2bb56d939f71c5ece2d61cf6680a3
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Rails 4.2, `ActionController::Metal` controllers did not include the
default headers from `ActionDispatch::Response`. However, through e16afe6, and a
general shift towards having `ActionController::Metal` objects contain
`ActionDispatch::Response` objects (instead of just returning an array
of status, headers, and body), this behavior was lost. This PR helps to
restore the original behavior by having `ActionController::Metal`
controllers generate Response objects without the default headers, while
`ActionController::Base` now overrides the factory method to make sure
its version does have the default headers.
|
|
|
|
| |
[ci skip]
|
|
|
| |
Include the content of the flash in the auto-generated etag
|
|
|
|
|
| |
At GitHub we need to handle parameter encodings that are not UTF-8. This
patch allows us to specify encodings per parameter per action.
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is a common pattern in the Rails community that when people want to
:xa
use any kind of helper that is defined inside app/helpers they includes
the helper module inside the controller like:
module UserHelper
def my_user_helper
# ...
end
end
class UsersController < ApplicationController
include UserHelper
def index
render inline: my_user_helper
end
end
This has problem because the helper can't access anything that is
defined in the view level context class.
Also all public methods of the helper become available in the controller
what can lead to undesirable methods being routed and behaving as
actions.
Also if you helper depends on other helpers or even Action View helpers
you need to include each one of these dependencies in your controller
otherwise your helper is not going to work.
We already have a helpers proxy at controller class level but that proxy
doesn't have access to the instance variables defined in the
controller.
With this new instance level helper proxy users can reuse helpers in the
controller without having to include the modules and with access to
instance variables defined in the controller.
class UsersController < ApplicationController
def index
render inline: helpers.my_user_helper
end
end
|
|
|
|
|
|
|
|
|
| |
There were a lot of protected instance variables in
AbsctractController::Rendering that were related to Action Controller
and Action View.
Moving to ActionController::Base's protected instance list we make it
closer to where they are really defined.
|
| |
|
|
|
|
|
| |
this means the reader doesn't need to lock, but does have the added cost
of a new object created for every controller
|
|\
| |
| | |
Remove dead code
|
| | |
|
| |
| |
| |
| |
| |
| | |
Since all controller instances are required to have a request and
response object, RackDelegation is no longer needed (we always have to
delegate to the response)
|
|/
|
|
| |
these ivars don't exist anymore, so we can remove them from the list
|
|
|
|
|
|
|
| |
Actions are processed through `dispatch`, so they should have the
request set on them before any user land code can be executed. Lets
stop setting _env on the controller, and give access to it through the
`env` method.
|
|\
| |
| |
| | |
Add documentation to get a running custom base controller [ci skip]
|
|/ |
|
| |
|
|
|
|
| |
skip]
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New default: the template digest is automatically included in your ETags.
When you call `fresh_when @post`, the digest for `posts/show.html.erb`
is mixed in so future changes to the HTML will blow HTTP caches for you.
This makes it easy to HTTP-cache many more of your actions.
If you render a different template, you can now pass the `:template`
option to include its digest instead:
fresh_when @post, template: 'widgets/show'
Pass `template: false` to skip the lookup. To turn this off entirely, set:
config.action_controller.etag_with_template_digest = false
|
|
|
|
| |
ref #14062
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
constant.
`view_assigns` can use the precalculated sets and remove instance
variables without allocating any extra arrays
|
|
|
|
|
|
|
|
|
| |
Fixing the typo which is formed a not required link. Check
here http://api.rubyonrails.org/classes/ActionController/Base.html
under paramters section
keeping it under tt tag
gets reverted here ec8ef1e1055c4e1598da13f49d30261f07f4a9b4
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 7de994fa215e9f4c2856d85034bc4dd7b65d0c01.
|
| |
|
| |
|
|
|
|
| |
We don't need them. They'll be loaded automaticly if AV will be included
|
|
|
|
|
|
| |
Make it clearer
[ci skip]
|
| |
|
| |
|
| |
|