[Catalyst] Re: implementing ajax

[KH]

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=3D514
http://jpsykes.com/47/practical-csrf-and-json-security


On Thu, Mar 13, 2008 at 5:57 AM, Aristotle Pagaltzis <pagaltzis at gmx.de>
wrote:

> * Jennifer Ahn <jenahn at stanford.edu> [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 =3D 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: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20080313/9b558=
ad2/attachment.htm