| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This is unnecessary now that we can just provide a file source
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous behaviour of render file: was essentially the same as
render template:, except that templates can be specified as an absolute
path on the filesystem.
This makes sense for historic reasons, but now render file: is almost
exclusively used to render raw files (not .erb) like public/404.html. In
addition to complicating the code in template/resolver.rb, I think the
current behaviour is surprising to developers.
This commit deprecates the existing "lookup a template from anywhere"
behaviour and replaces it with "render this file exactly as it is on
disk". Handlers will no longer be used (it will render the same as if
the :raw handler was used), but formats (.html, .xml, etc) will still be
detected (and will default to :plain).
The existing render file: behaviour was the path through which Rails
apps were vulnerable in the recent CVE-2019-5418. Although the
vulnerability has been patched in a fully backwards-compatible way, I
think it's a strong hint that we should drop the existing
previously-vulnerable behaviour if it isn't a benefit to developers.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Templates only have one variant, so we should not store it in an array.
This commit converts `variants` to `variant` and deprecates the plural
accessor
|
| |
|
|
|
|
|
| |
Templates only have one format. Before this commit, templates would be
constructed with a single element array that contained the format. This
commit eliminates the single element array and just implements a
`format` method. This saves one array allocation per template.
|
|
|
Every template that specifies a "virtual path" loses the template source
when the template gets compiled:
https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template.rb#L275
The "refresh" method seems to think that the source code for a template
can be recovered if there is a virtual path:
https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template.rb#L171-L188
Every call site that allocates a template object *and* provides a
"virtual path" reads the template contents from the filesystem:
https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/template/resolver.rb#L229-L231
Templates that are inline or literals don't provide a "virtual path":
https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/renderer/template_renderer.rb#L34
This commit introduces a `FileTemplate` type that subclasses `Template`.
The `FileTemplate` keeps a reference to the filename, and reads the
source from the filesystem. This effectively makes the template source
immutable.
Other classes depended on the source to be mutated while being compiled,
so this commit also introduces a temporary way to pass the mutated
source to the ERB (or whatever) compiler. See `LegacyTemplate`.
I think we should consider it an error to provide a virtual path on a
non file type template an non-file templates can't recover their source.
Here is an example:
https://github.com/rails/rails/blob/eda0f574f129fcd5ad1fc58b55cb6d1db71ea95c/actionview/lib/action_view/testing/resolvers.rb#L53
This provides a "virtual path" so the source code (a string literal) is
thrown away after compilation. Clearly we can't recover that string, so
I think this should be an error.
|
