Catalyst-View-JSON

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

          $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:

README  view on Meta::CPAN

    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') {

README  view on Meta::CPAN

    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

lib/Catalyst/View/JSON.pm  view on Meta::CPAN

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

=head1 CONFIG VARIABLES

=over 4

=item allow_callback

Flag to allow callbacks by adding C<callback=function>. Defaults to 0
(doesn't allow callbacks). See L</CALLBACKS> for details.

=item callback_param

Name of URI parameter to specify JSON callback function name. Defaults
to C<callback>. Only effective when C<allow_callback> is turned on.

=item expose_stash

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

lib/Catalyst/View/JSON.pm  view on Meta::CPAN

Another option would be to use I<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 I<\uXXXX>. You have to install
L<Encode::JavaScript::UCS> to use the encoding.

=head1 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 I<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') {

lib/Catalyst/View/JSON.pm  view on Meta::CPAN

B<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.

=head1 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.

=head2 Use callbacks only for public data

When you enable callbacks (JSONP) by setting C<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
C<allow_callback> is a static configuration of the View::JSON class.

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

=head2 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 C<[]>.

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

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