I am not against removing this (I personally don't have use for this anymore), but the reason behind the removal this seems unclear to me.
If it's just "let's remove this because no one uses this anymore" (and if that's true), or "Rails want to discourage this type of architecture in favour of moving these type of processing to the client", then fine. But I am not sure if I fully understand the security angle here. Specifically, in Egor's blog post: 1. *"Broken concept & architecture. This feels as weird as the client-side sending code that is going to be evaled on the server-side... wait... Rails programmers had similar thing for a while :/"* But in the context of a web application, by definition you are always sending JavaScript code from your server to be eval()-ed in the client (browser) :) Whether the code is in /assets/javascript or in your controller, there's really no difference here. So I'll have to assume you are talking about eval()-ing code that contains user-supplied data that's bad. Which is fair enough, considering there's usually a safer way to do this (encoding the user-supplied data as JSON first). But as Andrew pointed out on the Github issue, there might be legitimate use cases for using this to return code that does NOT contain user-supplied data. I think those use cases needs to be understood properly (and we need to investigate/suggest alternatives for those cases) to ensure we are not removing a useful feature just because it's subject to abuse. 2. *"**Escaping user content and putting it into Javascript can be more painful and having more pitfalls then normal HTML escaping. ... **There can be more special characters and XSS you should care about.**"* Is this not already adequately addressed by the escaping helpers Rails provide? If so, regardless of whether we remove the js responder, those issues should be reported and fixed in Rails itself. I just opened https://github.com/rails/rails/pull/13073 yesterday to patch json_escape to make it useful again (please provide feedback), and I plan to submit another PR to improve the docs on escape_javascript to make the intended use cases more clear. If it is already possible to correctly escape input for use in the JS responder, just that it's difficult to do it correctly, the problem might not lie in the JS responder pre-se and we should take this opportunity to address them. 3. *"JSONP-like data leaking. If app accepts GET request and responds with Javascript containing private data in it attacker can use fake JS functions to leak data from the response."* I assume you are talking about CSRF attacks where a page on a third-party domain can make requests to your site on your user's behalf. But like you said, this problem also exists in JSONP. In fact, it's probably much easier to exploit this in JSONP (because you can control the name of the callback) than a JS response that updates a certain part of the page. So I'm not sure if this is really JS responder's fault. And like Andrew said, in his use case there's nothing to leak. Maybe I am not understanding this point correctly. If you can provide some examples based on the apps you see in the field it will be very helpful. 4. *"UPD as pointed out on HN evaling response will mess with your global namespace and there is no way to jump into closure you created request in.."* (I suppose this is not related to security.) If you are doing a lot you should definitely architect your client-side JavaScript properly, that I agree 100% (I mainly write full-blown single page apps these day for my day job, so believe me when I say we are in agreement :). But in cases where you are delivering a small, simple payload to update a small part of the page, I don't know if that's super evil and should be strongly discouraged. I don't do this, so I'm not really in a good position to defend it. Again, maybe it's just a case of "no one uses this anymore so it's not worth supporting", and that's fine by me. But you brought up security, so I want to make sure we address your concerns properly. Godfrey On Thu, Nov 28, 2013 at 1:02 PM, Steve Schwartz <st...@alfajango.com> wrote: > A lot of people use the js responder with ujs, but there are often bugs > with how jQuery handles the automatic code execution of js ajax responses, > so I agree, it's something I wouldn't mind deprecating. > > One reason people tend to use js responders is to use js.erb to embed > values from ruby into the returned js, but I think a better way to do this > is to use json and HTML data attributes to embed values when necessary. > On Nov 28, 2013 3:49 PM, "Aaron Patterson" <tenderl...@ruby-lang.org> > wrote: > >> On Thu, Nov 28, 2013 at 12:41:37AM -0800, Egor Homakov wrote: >> > https://github.com/rails/rails/issues/12374#issuecomment-29446761 >> > >> > Here in discussion I proposed to deprecate JS responder because this >> > technique is insecure and not pragmatic way to transfer data. >> > It can be exploited in this >> > way >> http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html >> > >> > i find this bug very often so i know what i'm talking about. With it >> > attacker can steal user data and authenticity_token if templates with >> form >> > were leaked too. >> >> Removing it seems fine to me, but I suppose we should deprecate it >> first. Don't people need to specifically say "render js: whatever"? >> >> I think 100% of "render js:" cases can be implemented using JSON. But >> maybe I am wrong. >> >> -- >> Aaron Patterson >> http://tenderlovemaking.com/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rubyonrails-core+unsubscr...@googlegroups.com. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
