As I said before, I (or we, for whoever is in support) can solve the minor details, and provide solutions with a little bit of creativity. I am of the opinion that if you see points such as the ones you mentioned, you may also be able to see how to fix them, if you so desire. I have some suggestions.
> * Introducing this will break existing applications, which > already make use of h, since h isn't idempotent. As I said previously, this could be available as a configuration option, negating your remark about breaking existing applications. You would have to explicitly choose to break your own application. And where would that leave you? Providing the option to enable the XSS security for those who do choose for it. When enabled, the h function would be wiser at detecting what it is that it's encoding. One idea is to have a safe list of tags and html code which can be verified, such as those found on the > * If <%= expr %> already produces valid html (or a html > fragment like "</p>", which becomes valid through the page > context), applying h to expr will produce garbage. Again, this would be solved with the configuration option. But even if it was default in 2.0 as core, we could consider utilizing the non-xss method, something like <%=r for raw, which would provide the ability to switch the default to a raw version of the string, instead of encoding it. Another idea might be to have a .xss extension, which defaults to using the <%=h method on all print statements, or does a scan of the document for all XSS vulnerabilities we are able to detect. This may even be a bit overkill, but maybe not? <%=r '<p>This is raw html' %>, would be an elegant way to solve the do-not-touch-this-html issue, but would require people to reverse their opinions of what <%= does. > * And of course, it would severely hurt performance. I wouldn't mind seeing a benchmark of <%= '<p>test</p> %> vs. <%=h '<p>test</p>' %> to back this statement up. Understandably, the h method does do a bit more. But how much more? And what about caching? > So -10 from me. Hmm.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
