[Catalyst] implementing ajax

[Jennifer Ahn]

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:jon at jrock.us]
>> 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 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/
>
>