I believe the primary use case for js responder is remote forms, where you are not doing the request yourself, so a js response is the simplest and most natural approach there. This is not inherently insecure so should not be deprecated just because it does not feel good to some.
On Thursday, November 28, 2013 3:49:40 PM UTC-5, Aaron Patterson 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.
