Provided by: libcatalyst-view-json-perl_0.37-2_all 
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} = 2;
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.
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.
json_encoder_args
An optional hashref that supplies arguments to JSON::MaybeXS used when creating a new
object.
use_force_bom
If versions of this view older than 0.36, there was some code that added a UTF-8 BOM
marker to the end of the JSON string when the user agent was Safari. After looking at
a lot of existing code I don't think this is needed anymore so we removed it by
default. However if this turns out to be a problem you can re enable it by setting
this attribute to true. Possible a breaking change so we offer this workaround.
You may also override the method 'user_agent_bom_test' which received the current
request user agent string to try and better determine if this is needed. Patches for
this welcomed.
METHODS
process
Standard target of $c->forward used to prepare a response
render
The methods accepts either of the following argument signatures in order to promote
compatibility with the semi standard render method as define in numerous Catalyst views on
CPAN:
my $json_string = $c->view('JSON')->render($c, undef, $data);
my $json_string = $c->view('JSON')->render($c, $data);
Given '$data' returns the JSON serialized version, or throws and error.
OVERRIDING JSON ENCODER
By default it uses JSON::MaybeXS::encode_json to serialize perl data structure into JSON
data format. If you want to avoid this and encode with your own encoder (like passing
different options to JSON::MaybeXS etc.), you can implement the "encode_json" method in
your View class.
package MyApp::View::JSON;
use base qw( Catalyst::View::JSON );
use JSON::MaybeXS ();
sub encode_json {
my($self, $c, $data) = @_;
my $encoder = JSON::MaybeXS->new->(ascii => 1, pretty => 1, allow_nonref => 1);
$encoder->encode($data);
}
1;
ENCODINGS
NOTE Starting in release v5.90080 Catalyst encodes all text like body returns as UTF8. It
however ignores content types like application/json and assumes that a correct JSON
serializer is doing what it is supposed to do, which is encode UTF8 automatically. In
general this is what this view does so you shoulding need to mess with the encoding flag
here unless you have some odd case.
Also, the comment about regard 'browser gotcha's' was written a number of years ago and I
can't say one way or another if those gotchas continue to be common in the wild.
NOTE Setting this configuration has no bearing on how the actual serialized string is
encoded. This ONLY sets the content type header in your response. By default we set the
'utf8' flag on JSON::MaybeXS so that the string generated and set to your response body is
proper UTF8 octets that can be transmitted over HTTP. If you are planning to do some
alternative encoding you should turn off this default via the "json_encoder_args":
MyApp::View::JSON->config(
json_encoder_args => +{utf8=>0} );
NOTE In 2015 the use of UTF8 as encoding is widely standard so it is very likely you
should need to do nothing to get the correct encoding. The following documentation will
remain for historical value and backcompat needs.
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.
NOTE For another way to enable JSONP in your application take a look at
Plack::Middleware::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 recommend 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 response
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);
NOTE The above comments were written a number of years ago and I would take then with a
grain of salt so to speak. For now I will leave them in place but not sure they are
meaningful in 2015.
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_callback", 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_callback: 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_callback" 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 possibility 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::MaybeXS, 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/>