I am -1 for deprecating the js responders Personally I find using the js.erb templates much easier, more DRY and more expressive then returning a HTML string as a JSON element. Any JavaScript in the js.erb should be specific to initializing the rendered HTML and would exist in the event handler of the AJAX call anyways, so having it in the assets seems of little benefit. All the reusable code should live in the assets either way.
It does not seem like removing it provides any benefit to the people who would prefer to use all JSON. So, other than forcing a preference on the community, why deprecate it? On Thu, Nov 28, 2013 at 7:34 PM, Maurizio De Santis < desantis.mauri...@gmail.com> wrote: > 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 <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" <tende...@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-co...@googlegroups.com. >>>> To post to this group, send email to rubyonra...@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-co...@googlegroups.com. >>> To post to this group, send email to rubyonra...@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. > -- Scott Johnson -- 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.
