Marius, your solution is not much different from responding a render :json : you send only the data, and the processing code is already on client side; transponder.js seems to me that it adds an abstraction level in order to manage the data, but it is different from RJS, which sends the execution code too, that is necessary for running the examples made before, like Disqus, or single page apps.
transponder.js a good solution if you don't want / need to send the execution code, as render :json , but I think I got that RJS is necessary for other contexts. -- Maurizio De Santis 2013/12/2 Marius Corîci <[email protected]> > I much appreciate RoR, its community Homakov included. I never saw RoR > security team at least one time to appreciate Homakov's findings. Perhaps > you should take it closer by first recognize his security work over RoR. > I'm quite sure that Homakov would have comply to your rules in the end. > > > On Monday, December 2, 2013 5:47:07 PM UTC+2, DHH wrote: >> >> Please stop conflating the discovery of a security issue with the >> philosophical waxing about architecture. It's not helping the case. As >> stated previously, responding with JS is not only a wonderful architectural >> pattern, it's also not going anywhere. Not in a gem, not in a deprecation, >> not anywhere. We'll fix the security issue, and Rails will continue to >> proudly champion the use of this great pattern. >> >> Guess what, it won't be the last security issue Rails ever has. Just like >> it won't be the last security issue any piece of software ever has. But we >> need to level up as a community in our handling of these issues. >> >> Frankly, I'm surprised that people are willing to hire Homakov for any >> work in the area given his reputation for irresponsible disclosure. Finding >> a legit security issues is a great services, but disregarding all security >> issue management protocols in their publication is doing a disservice to >> all who would otherwise benefit from the work. >> >> Rails has had a codified security process for many years now. It's >> available for all to read on http://rubyonrails.org/security. Making a >> blog post on your personal site isn't one of the channels listed as a >> responsible way of disclosing discoveries. Posting specific 0-day attack >> vectors against affected sites is not one either. >> >> Making a public report over a holiday weekend, and then, when the >> response to the report doesn't immediately follow the proposed solution >> (remove the feature), go off the reservation with specific attacks is just >> plain irresponsible. No two ways about it. It also goes to undermine any >> other recommendations or suggestions coming from said reporter. >> >> So. Damage is already done for this issue. But lest it encourages others >> to act as irresponsibly as Homakov has done of this issue, I hope others >> take a broader approach for future issues. Report systemic or framework >> issues per the reporting instructions on http://rubyonrails.org/security. >> Report specific application issues directly to application developers >> responsibly per their reporting instructions (see https://37signals.com/ >> security-response for the one we use at 37signals). >> >> Presumably we're all in the same boat here: Make Rails better and more >> secure. Let's row like we mean that. The Rails security team (Michael >> Koziarski, Jeremy Kemper, and Aaron Patterson) has worked hard in the past >> to provide us with a good process, they've followed that process, and they >> deserve our thanks and support. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ruby on Rails: Core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/rubyonrails-core/rwzM8MKJbKU/unsubscribe > . > To unsubscribe from this group and all its topics, 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. > -- 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.
