I think the 2007 Calendar had a great Javascript/JSON/Catalyst tutorial. http://catalyst.perl.org/calendar/2007/9
If you've never used javascript with callbacks before, or even if you have, it's a great reference. Honestly, I find myself modeling much of how I use javascript after how that example works, as it's really a simple approach - and simple is better imho. The only /real/ vulnerability to JSON - as I understand it, and I could be wrong - is when you read JSON from untrusted hosts. JSON doesn't have the requirement like XML does that the response come the from the same host that you requested it from - and this where some of the cross-site scripting exploits come in to play (as I understand it). But I'm sure there are some pretty good ways of mitigating that risk. The two ways I can think of off the top of my head are: including a sha-1 challenge in every request, and sha-1 response with the returned data; or just crypt every data field with a cheap encryption scheme using a certificate you push to the client. Actually, I just read a great article on pushing certs to the client: http://drnicwilliams.com/2008/02/22/zero-sign-on-with-client-certificates/ Infact, here a couple articles that hit the AJAX(y) JSON/XSS/etc.. vulnerabilities - but really, look at the data your serving and your potential audience when deciding on the level of security you need: http://secwatch.org/advisories/1020538/ http://www.securityfocus.com/infocus/1881 http://jibbering.com/blog/?p=514 http://jpsykes.com/47/practical-csrf-and-json-security On Thu, Mar 13, 2008 at 5:57 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote: > * Jennifer Ahn <[EMAIL PROTECTED]> [2008-03-12 18:20]: > > I'm sure that JSON and all the other goodies are perfect tools > > for implementing ajax, but i would like to learn what's really > > going on in teh black box before I use it. > > JSON is not a "blackbox." (Does that even mean anything?) It's > simply a data format. It's no different from XML in this respect, > it's just a much simpler format than XML that looks exactly like > Javascript (though that doesn't mean you should `eval` it, as > Jonathan said) and deserialises to plain old in-memory Javascript > data structure. Therefore it's much easier to work with on the > client than XML is: you write regular Javascript object/array > accesses instead of painstakingly examining a DOM. > > That's it. That's all there is to it. > > > So far, my javascript is able to send an xmlhttprequest to my > > catalyst controller method which then does some processes and > > outputs data into an xml document. i'm having trouble sending > > that document over to my xmlhttprequest.responseXML object. in > > my controller: > > my $writer = new XML::LibXML::Document; > > ... do some process and spit out into an xml document... > > $c->response->content_type('text/xml'); > > $c->response->write($writer); > > > > When the xmlhttprequest is ready, I plan to parse the > > req.responseXML object using XMLSerializer in my javascript > > code. > > The code to send JSON looks pretty much identical. > > use JSON::XS; > $c->res->content_type('application/json'); > $c->res->body(encode_json($c->stash)); > > Regards, > -- > Aristotle Pagaltzis // <http://plasmasturm.org/> > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > -- do() || do_not(); // try() -------------------------------- Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam -------------------------------- http://www.kylehultman.com
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
