trusty (3) Catalyst::View::JSON.3pm.gz

NAME

       Catalyst::View::JSON - JSON view for your data

SYNOPSIS

         # lib/MyApp/View/JSON.pm
         package MyApp::View::JSON;
         use base qw( Catalyst::View::JSON );
         1;

         # configure in lib/MyApp.pm
         MyApp->config({
             ...
             'View::JSON' => {
                 allow_callback  => 1,    # defaults to 0
                 callback_param  => 'cb', # defaults to 'callback'
                 expose_stash    => [ qw(foo bar) ], # defaults to everything
             },
         });

         sub hello : Local {
             my($self, $c) = @_;
             $c->stash->{message} = 'Hello World!';
             $c->forward('View::JSON');
         }

DESCRIPTION

       Catalyst::View::JSON is a Catalyst View handler that returns stash data in JSON format.

CONFIG VARIABLES

       allow_callback
           Flag to allow callbacks by adding "callback=function". Defaults to 0 (doesn't allow callbacks). See
           "CALLBACKS" for details.

       callback_param
           Name of URI parameter to specify JSON callback function name. Defaults to "callback". Only effective
           when "allow_callback" is turned on.

       expose_stash
           Scalar, List or regular expression object, to specify which stash keys are exposed as a JSON
           response. Defaults to everything. Examples configuration:

             # use 'json_data' value as a data to return
             expose_stash => 'json_data',

             # only exposes keys 'foo' and 'bar'
             expose_stash => [ qw( foo bar ) ],

             # only exposes keys that matches with /^json_/
             expose_stash => qr/^json_/,

           Suppose you have data structure of the following.

             $c->stash->{foo} = [ 1, 2 ];
             $c->stash->{bar} = [ 3, 4 ];

           By default, this view will return:

             {"foo":[1,2],"bar":2}

           When you set "expose_stash => [ 'foo' ]", it'll return

             {"foo":[1,2]}

           and in the case of "expose_stash => 'foo'", it'll just return

             [1,2]

           instead of the whole object (hashref in perl). This option will be useful when you share the method
           with different views (e.g. TT) and don't want to expose non-irrelevant stash variables as in JSON.

       json_driver
             json_driver: JSON::Syck

           By default this plugin uses JSON to encode the object, but you can switch to the other drivers like
           JSON::Syck, whichever JSON::Any supports.

       no_x_json_header
             no_x_json_header: 1

           By default this plugin sets X-JSON header if the requested client is a Prototype.js with X-JSON
           support. By setting 1, you can opt-out this behavior so that you can do eval() by your own. Defaults
           to 0.

OVERRIDING JSON ENCODER

       By default it uses JSON::Any to serialize perl data strucuture into JSON data format. If you want to
       avoid this and encode with your own encoder (like passing options to JSON::XS etc.), you can implement
       "encode_json" method in your View class.

         package MyApp::View::JSON;
         use base qw( Catalyst::View::JSON );

         use JSON::XS ();

         sub encode_json {
             my($self, $c, $data) = @_;
             my $encoder = JSON::XS->new->ascii->pretty->allow_nonref;
             $encoder->encode($data);
         }

         1;

ENCODINGS

       Due to the browser gotchas like those of Safari and Opera, sometimes you have to specify a valid charset
       value in the response's Content-Type header, e.g. "text/javascript; charset=utf-8".

       Catalyst::View::JSON comes with the configuration variable "encoding" which defaults to utf-8. You can
       change it via "YourApp->config" or even runtime, using "component".

         $c->component('View::JSON')->encoding('euc-jp');

       This assumes you set your stash data in raw euc-jp bytes, or Unicode flagged variable. In case of Unicode
       flagged variable, Catalyst::View::JSON automatically encodes the data into your "encoding" value (euc-jp
       in this case) before emitting the data to the browser.

       Another option would be to use JavaScript-UCS as an encoding (and pass Unicode flagged string to the
       stash). That way all non-ASCII characters in the output JSON will be automatically encoded to JavaScript
       Unicode encoding like \uXXXX. You have to install Encode::JavaScript::UCS to use the encoding.

CALLBACKS

       By default it returns raw JSON data so your JavaScript app can deal with using XMLHttpRequest calls.
       Adding callbacks (JSONP) to the API gives more flexibility to the end users of the API: overcome the
       cross-domain restrictions of XMLHttpRequest. It can be done by appending script node with dynamic DOM
       manipulation, and associate callback handler to the returned data.

       For example, suppose you have the following code.

         sub end : Private {
             my($self, $c) = @_;
             if ($c->req->param('output') eq 'json') {
                 $c->forward('View::JSON');
             } else {
                 ...
             }
         }

       "/foo/bar?output=json" will just return the data set in "$c->stash" as JSON format, like:

         { result: "foo", message: "Hello" }

       but "/foo/bar?output=json&callback=handle_result" will give you:

         handle_result({ result: "foo", message: "Hello" });

       and you can write a custom "handle_result" function to handle the returned data asynchronously.

       The valid characters you can use in the callback function are

         [a-zA-Z0-9\.\_\[\]]

       but you can customize the behaviour by overriding the "validate_callback_param" method in your View::JSON
       class.

       See <http://developer.yahoo.net/common/json.html> and
       <http://ajaxian.com/archives/jsonp-json-with-padding> for more about JSONP.

INTEROPERABILITY

       JSON use is still developing and has not been standardized. This section provides some notes on various
       libraries.

       Dojo Toolkit: Setting dojo.io.bind's mimetype to 'text/json' in the JavaScript request will instruct
       dojo.io.bind to expect JSON data in the response body and auto-eval it. Dojo ignores the server response
       Content-Type. This works transparently with Catalyst::View::JSON.

       Prototype.js: prototype.js will auto-eval JSON data that is returned in the custom X-JSON header. The
       reason given for this is to allow a separate HTML fragment in the response body, however this of limited
       use because IE 6 has a max header length that will cause the JSON evaluation to silently fail when
       reached. The recommened approach is to use Catalyst::View::JSON which will JSON format all the response
       data and return it in the response body.

       In at least prototype 1.5.0 rc0 and above, prototype.js will send the X-Prototype-Version header. If this
       is encountered, a JavaScript eval will be returned in the X-JSON resonse header to automatically eval the
       response body, unless you set no_x_json_header to 1. If your version of prototype does not send this
       header, you can manually eval the response body using the following JavaScript:

         evalJSON: function(request) {
           try {
             return eval('(' + request.responseText + ')');
           } catch (e) {}
         }
         // elsewhere
         var json = this.evalJSON(request);

SECURITY CONSIDERATION

       Catalyst::View::JSON makes the data available as a (sort of) JavaScript to the client, so you might want
       to be careful about the security of your data.

   Use callbacks only for public data
       When you enable callbacks (JSONP) by setting "allow_callbacks", all your JSON data will be available
       cross-site. This means embedding private data of logged-in user to JSON is considered bad.

         # MyApp.yaml
         View::JSON:
           allow_callbacks: 1

         sub foo : Local {
             my($self, $c) = @_;
             $c->stash->{address} = $c->user->street_address; # BAD
             $c->forward('View::JSON');
         }

       If you want to enable callbacks in a controller (for public API) and disable in another, you need to
       create two different View classes, like MyApp::View::JSON and MyApp::View::JSONP, because
       "allow_callbacks" is a static configuration of the View::JSON class.

       See <http://ajaxian.com/archives/gmail-csrf-security-flaw> for more.

   Avoid valid cross-site JSON requests
       Even if you disable the callbacks, the nature of JavaScript still has a possiblity to access private JSON
       data cross-site, by overriding Array constructor "[]".

         # MyApp.yaml
         View::JSON:
           expose_stash: json

         sub foo : Local {
             my($self, $c) = @_;
             $c->stash->{json} = [ $c->user->street_address ]; # BAD
             $c->forward('View::JSON');
         }

       When you return logged-in user's private data to the response JSON, you might want to disable GET
       requests (because script tag invokes GET requests), or include a random digest string and validate it.

       See <http://jeremiahgrossman.blogspot.com/2006/01/advanced-web-attack-techniques-using.html> for more.

AUTHOR

       Tatsuhiko Miyagawa <miyagawa@bulknews.net>

LICENSE

       This library is free software; you can redistribute it and/or modify it under the same terms as Perl
       itself.

CONTRIBUTORS

       Following people has been contributing patches, bug reports and suggestions for the improvement of
       Catalyst::View::JSON.

       John Wang kazeburo Daisuke Murase Jun Kuriyama Tomas Doran

SEE ALSO

       Catalyst, JSON, Encode::JavaScript::UCS

       <http://www.prototypejs.org/learn/json> <http://docs.jquery.com/Ajax/jQuery.getJSON>
       <http://manual.dojotoolkit.org/json.html> <http://developer.yahoo.com/yui/json/>