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.

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.

Thanks for everybody's input. I look forward to the day I can explore JSON and others!

Jennifer

Matt Pitts wrote:
-----Original Message-----
From: Jonathan Rockway [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 12:12 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] implementing ajax

* On Wed, Mar 12 2008, Matt Pitts wrote:
The main reason against JSON for me is security. Something that can
be
eval'd is very dangerous and I'm sure we're all aware of the cross-
site
vulnerabilities that take advantage of JSON returned data.
Don't parse JSON with eval.  Use a parser.  (How do you think Perl
parses JSON?)
It's a code vs. data issue.  Yes, evalling code is dangerous.  So
don't
do that.  Treat your data as data and you won't have a problem.

Sure, I can do this in my own client-side JS, but what if I can't trust
the client? Even if my returned JSON is purely JSON structure (no "var x
= { <JSON DATA> };", just "{ <JSON DATA> }") can I still be guaranteed
that if someone does:

<script type="text/javascript"
src="http://myapp.com/some/cat/action/that/returns/json/data";></script>

in their own pages that the local JS engine won't actually put my data
(with potential user info) into memory and allow a malicious person to
get it? I see where you could maybe make this same argument against XML,
but since JSON is really, really close to being eval-able as JS code
whereas XML is not, I'd rather err on the side of caution.

If data is data and you have to use a parser anyway, then again, why not
use a format that is less vulnerable to malicious access?

v/r
-matt pitts



_______________________________________________
List: Catalyst@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/


_______________________________________________
List: Catalyst@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/

Reply via email to