About the HTML rendering use case, I would point out that it could be adequately solved using render_to_string, and IMHO more elegantly, since the related JS could be included in the assets, and so organized toghether with the other JS source.
I can't think about use cases where RJS is preferable over render :json, does anyone do? Il giorno giovedì 28 novembre 2013 22:42:26 UTC+1, Godfrey Chan ha scritto: > > 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 > <[email protected]<javascript:> > > 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" >> <[email protected]<javascript:>> >> 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 [email protected] <javascript:>. >>> To post to this group, send email to >>> [email protected]<javascript:> >>> . >>> 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 [email protected] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
