[Catalyst] Re: implementing ajax
* 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: 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/
[Catalyst] Re: Http Status Chart
* Matt Lawrence [EMAIL PROTECTED] [2008-03-13 10:55]: Aristotle Pagaltzis wrote: So when would 403 happen? F.ex. if access to the resource is restricted to certain IP ranges, and you are requesting the resource from an IP outside of those. Or in case of Apache, you are asking for a URI that’s served from the file system, but the web server does not have permission to read that file. Or you request a URI with a trailing slash, but the corresponding directory has no `index.html` and the server is not configured to generate directory listings. Is there a particular status code for denying access based on application-level authentication, or should you just use 200 for that? Errm. :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.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/
Re: [Catalyst] Re: Http Status Chart
Aristotle Pagaltzis wrote: * Andrew Rodland [EMAIL PROTECTED] [2008-03-12 05:55]: Anyway, you get a 401 if the server doesn't know who you are, and it thinks that if you were the right person you might be able to perform that action. You get a 403 if you're not allowed to do that despite who you may or may not be. Exactly. 401 means “use a different set of credentials and try again”; 403 means “go away, you don’t get to see this.” So when would 403 happen? F.ex. if access to the resource is restricted to certain IP ranges, and you are requesting the resource from an IP outside of those. Or in case of Apache, you are asking for a URI that’s served from the file system, but the web server does not have permission to read that file. Or you request a URI with a trailing slash, but the corresponding directory has no `index.html` and the server is not configured to generate directory listings. Etc. Note that RFC 2616 also says that the web server is allowed to send 404 instead of 403 when it doesn’t want to reveal the existence of a particular resource to third parties. The RFC also says that 401 responses MUST include a WWW-Authenticate header field, implying that it is specifically related to HTTP-level authentication. Is there a particular status code for denying access based on application-level authentication, or should you just use 200 for that? Matt ___ 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/
Re: [Catalyst] Re: implementing ajax
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: 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/
--
do() || do_not(); // try()
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane
mittam
http://www.kylehultman.com
___
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/
Re: [Catalyst] Re: implementing ajax
On Thu, Mar 13, 2008 at 6:41 AM, KH [EMAIL PROTECTED] wrote: 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/ This is incorrect, you can read XML and JSON from 3rd party domains if you know how to instruct the browser to do it. The browser will only limit host if you use XmlHttpRequest as the transport. The format of the data has nothing to do with the security rules applied to transport. If you try to do an XmlHttpRequest to a different domain, it will fail. It doesn't know anything at all about the format - you can send anything: plain text, html, JSON, PHP Serialization. To handle cross-domain requests, you can use an iframe transport and it will work for any other domain, regardless of the wireformat. Cross-site scripting is a completely different beast, though. The real core issue is that relying on the browser to always do what you want is not a good idea, much like trusting the referrer headers. Just don't. Code responsibly, and JSON and XML are both equal in this regard - done responsibly the only difference is personal taste. -J ___ 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/
Re: [Catalyst] Re: implementing ajax
One JSON security tangent worth knowing:
http://bob.pythonmac.org/archives/2007/04/05/fortify-javascript-
hijacking-fud/
Why I mentioned earlier, wrap it in {}.
-Ashley
___
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/
[Catalyst] DBIx::Class model for Form::Processor
If anybody is interested in trying my DBIx::Class model for Form::Processor let me know. I'm working on tests and packaging it for CPAN now. Gerda Shank ___ 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/
Re: [Catalyst] DBIx::Class model for Form::Processor
On Thu, 13 Mar 2008 14:53:51 -0400 Gerda Shank [EMAIL PROTECTED] wrote: If anybody is interested in trying my DBIx::Class model for Form::Processor let me know. I'm working on tests and packaging it for CPAN now. Gerda Shank I'm very interested! Looking forward to the CPAN package. ;-) -- |\ /|| | ~ ~ | \/ ||---| `|` ? ||ichael | |iggins\^ / michael.higgins[at]evolone[dot]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/
RE: [Catalyst] Re: implementing ajax
-Original Message- From: J. Shirley [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 11:51 AM To: The elegant MVC web framework Subject: Re: [Catalyst] Re: implementing ajax On Thu, Mar 13, 2008 at 6:41 AM, KH [EMAIL PROTECTED] wrote: 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/ This is incorrect, you can read XML and JSON from 3rd party domains if you know how to instruct the browser to do it. The browser will only limit host if you use XmlHttpRequest as the transport. The format of the data has nothing to do with the security rules applied to transport. If you try to do an XmlHttpRequest to a different domain, it will fail. It doesn't know anything at all about the format - you can send anything: plain text, html, JSON, PHP Serialization. To handle cross-domain requests, you can use an iframe transport and it will work for any other domain, regardless of the wireformat. Cross-site scripting is a completely different beast, though. The real core issue is that relying on the browser to always do what you want is not a good idea, much like trusting the referrer headers. Just don't. Code responsibly, and JSON and XML are both equal in this regard - done responsibly the only difference is personal taste. I'll have to concede to the greater knowledge levels of those around me. I guess JSON just scares me more because of how close it is to being eval-able by a malicious client and captured with a simple script tag. However, that's probably more a personal taste at this point. 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/
[Catalyst] problem on $c-res-body(*STDOUT);
sub test_body : Local {
my ($self, $c) = @_;
$c-res-body(*STDOUT);
print a\n;
print b\n;
}
I get:
a
b
HTTP/1.0 200 OK
Cache-Control: no-cache, must-revalidate, max-age=0
Connection: keep-alive
Date: Fri, 14 Mar 2008 02:58:50 GMT
Pragma: no-cache
Content-Length: 31
Set-Cookie: zorpia_session=6ef8f841a6f678e09621936e10c52f33eb442f57; path=/
Status: 200
X-Catalyst: 5.7012
*Catalyst::Engine::HTTP::Remote
how to get the correct stuff. I tried to call $c-finalize_headers();
before -body, no help.
Thanks.
--
Fayland Lam // http://www.fayland.org/
Foorum based on Catalyst // http://www.foorumbbs.com/
___
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/
