Changes default render behavior from file to template. #16888
Conversation
|
I'll fix the specs, but want to have the conversation first, because it has some impacts outside of ActionView. |
|
👍 to the idea |
|
👍. We have wanted to do this change since Rails 3 but we dropped the ball somewhere along the way. With Rails 5 coming, it seems to be the perfect time to get this in. |
|
I'll finish it up then. Thanks for the feedback. |
|
should this go through a deprecation cycle in 4.2? |
|
If we want to deprecate we need to ask users to explicitly say |
|
@rafaelfranca, the change is only to change the default from To clarify, most people who are using this are probably assuming it defaulted to template, and not to file, and so are unlikely to experience issues. It's likely only the cases where someone in fact knew that not supplying an options hash defaulted to That being said, I'm happy to follow instructions, and just need guidance on what should happen where, and when. |
|
I know, I just pointing if we are going to add deprecation message the only way of people remove the message from their logs is changing the code to explicitly use For example if we add deprecation message to: And we show the message: What would the users will have to do to remove this deprecation warning? |
|
Ah, point taken. So, we'd need to verify that the file is within a views path, and if it is don't display the deprecation warning, else display it. Seems hard given what I understand of how that part of the system works currently. |
|
Nevermind, I understand what you mean. |
|
Yeah, and maybe not worth to show any deprecation message. Since we are going to apply this change in a major bump and, as you said, users will probably not notice something changed I'd go without deprecation and with a note in the upgrading guides. |
Changes default render behavior from file to template.
|
Oh, wow. I was going to fix specs from the other gems first. As long as that's known, awesome. :) |
|
@jejacks0n Sorry, no, not known. 😅 I didn't know we have open action items on this one, what gems were you referring to? |
|
ActionController and a few others had failing tests. I only adjusted the ActionView tests as a proof, but it apparently has usage outside of that in other tests. |
|
I assume any call to |
This reverts commit 07635a7, reversing changes made to 1b5f61a. Reason: it's not ready 💣, see #16888 (comment)
|
Oops, I reverted. We should definitely should get those fixed 😄 |
…ate"" This reverts commit 585e756.
…ate"" This reverts commit 585e756.
|
@chancancode what's the status of this? Is it in, or was it reverted? In either case, thanks for fielding this, I was pulled away on work stuff. |
…ate"" This reverts commit 585e756. Conflicts: actionview/CHANGELOG.md guides/source/4_2_release_notes.md
Currently the default behavior of
render "foo/bar"is to expand torender file: "foo/bar".That means that the file being looked up is not restricted to the view paths, or the rails root path, and can lead to potentially vulnerable leaks from the filesystem.
This pull request changes the default behavior to
render template: "foo/bar"instead ofrender file: "foo/bar", which is restricted to the view paths, as exposing a high level of access to the file system outside of rails views should potentially be explicitly opt-in and not the default.This may result in a more secure system without having to know the low level underpinnings of the ActionView::Rendering implementation, and I'm submitting this to open a conversation about it. When I first came across this it appeared to be a security issue, and reached out to the security team before looking into it and realizing it was the behavior as designed.