On Tue, Jan 10, 2012 at 6:00 PM, tetsuo <[email protected]> wrote: > It works well as it is, and reimplementing it could introduce new, > unknown bugs. But if it becomes much cleaner, it may well worth the > risk. > > Another issues: > - will this change introduce a new depency on a third-party JSON > library, like jackson or json-lib, or will Wicket roll its own JSON > parser/generator?
I added json.org/json2 classes in Wicket's code It is simple and serves the needs we have so far. I don't mind to change it to something else too. in -extensions we have optional dep to jackson for JsonRequestLogger > - will JSON be more or less readable than XML in the AJAX debug panel? > As it is now, the html and javascript sections are escaped only with > <![CDATA[]]>, leaving the contents intact. As I understand, the JSON > output would be full of backslash escapes for quotes, making it quite > unreadable (unless enhance the panel to display it properly, of > course). So far I don't see any big benefit in JSON responses... > > Tetsuo > > > > On Tue, Jan 10, 2012 at 1:47 PM, Bertrand Guay-Paquet > <[email protected]> wrote: >> >>> I don't fully understand the blog post about the security problems. From >>> what >>> I can see, you need to be able to render a mallicious script tag to be >>> able to >>> intercept the JSON data. But if you are able to do that, there are much >>> bigger >>> problems. >> >> Indeed. If a malicious script can be injected, the DOM can be completely >> controlled and intercepted no matter what kind of encoding is used for the >> ajax response. However, the technique described in the blog means that raw >> components of a JSON response which are not added to the DOM can be >> intercepted by a malicious script by overloading array methods. >> >> I am unconvinced that using xml responses solves this problem though. Can't >> the javascript functions processing an xml response be overloaded just as >> well to capture it? >> -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
