view release on metacpan or search on metacpan
t/lib/TestApp/Controller/Action/Chained.pm view on Meta::CPAN
#
# Simple parent/child action test
#
sub foo :PathPart('chained/foo') :CaptureArgs(1) :Chained('/') {
}
sub endpoint :PathPart('end') :Chained('/action/chained/foo') :Args(1) { }
#
# Parent/child test with two args each
#
sub foo2 :PathPart('chained/foo2') :CaptureArgs(2) :Chained('/') { }
sub endpoint2 :PathPart('end2') :Chained('/action/chained/foo2') :Args(2) { }
#
# three chain with concurrent endpoints
#
sub one :PathPart('chained/one') :Chained('/') :CaptureArgs(1) { }
sub two :PathPart('two') :Chained('/action/chained/one') :CaptureArgs(2) { }
sub three_end :PathPart('three') :Chained('two') :Args(3) { }
view release on metacpan or search on metacpan
sub midpoint :Chained('set_model_by_return') PathPart('') CaptureArgs(0) {
my ($self, $c) = @_;
}
sub endpoint :Chained('midpoint') PathPart('') Args(0) {
my ($self, $c) = @_;
$c->res->body(ref $c->model);
}
sub set_view_by_return :Chained(/) CaptureArgs(0) {
sub midpoint2 :Chained('set_view_by_return') PathPart('') CaptureArgs(0) {
my ($self, $c) = @_;
}
sub endpoint2 :Chained('midpoint2') PathPart('') Args(0) {
my ($self, $c) = @_;
$c->res->body(ref $c->view);
}
package MyApp;
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/ForwardChained.pm view on Meta::CPAN
# In your application class
use Catalyst qw/ ForwardChained /;
# ... somwhere else:
$c->forward_to_chained( [ qw/ chained endpoint /, [ qw/ args / ] );
$c->forward_to_chained( 'chained/endpoint', [ qw/ args / ] );
=head2 Example 1
Having some controller:
lib/Catalyst/Plugin/ForwardChained.pm view on Meta::CPAN
$VERSION = '0.03';
=head2 forward_to_chained
forwards to a certain chained action endpoint ..
$c->forward_to_chained( "some/path", [ qw/ arg1 arg2 arg3 / ] );
$c->forward_to_chained( [qw/ some path /], [ qw/ arg1 arg2 arg3 / ] );
=cut
lib/Catalyst/Plugin/ForwardChained.pm view on Meta::CPAN
return ;
}
=head2 get_chained_action_endpoints
returns array or arrayref of endpoints.. to help you find the one you need
my @endpoints = $c->get_chained_action_endpoints;
my $endpoints_ref = $c->get_chained_action_endpoints;
=cut
sub get_chained_action_endpoints {
my ( $c ) = @_;
my $actions_ref = $c->dispatcher->action_hash;
my @endpoints =
sort
grep {
defined $actions_ref->{ $_ }->{ attributes } &&
ref $actions_ref->{ $_ }->{ attributes }->{ Chained }
}
grep { ! /(?:^|\/)_[A-Z]+$/ } keys %{ $actions_ref }
;
return wantarray ? @endpoints : \@endpoints;
}
view release on metacpan or search on metacpan
examples/lib/Example/JSONRPC/Controller/Root.pm view on Meta::CPAN
BEGIN { extends 'Catalyst::Controller' }
__PACKAGE__->config( namespace => '' );
# A JSON-RPC endpoint. Handlers are registered per request (cheap here); a real
# app would register them once at setup. Each handler gets the request's params
# and returns the result; an unregistered method yields a -32601 error.
sub rpc :Path('/rpc') :Args(0) {
my ( $self, $c ) = @_;
$c->jsonrpc_register( echo => sub ($p) { $p } );
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/JSONRPC.pm view on Meta::CPAN
=over 4
=item $c->json_rpc(%attrs)
Call this method from a controller action to set it up as a endpoint
for RPC methods in the same class.
Supported attributes:
=over 8
lib/Catalyst/Plugin/JSONRPC.pm view on Meta::CPAN
This module uses C<Remote> attribute, which indicates that the action
can be dispatched through RPC mechanisms. You can use this C<Remote>
attribute and integrate JSON-RPC and XML-RPC together, for example:
sub xmlrpc_endpoint : Regexp('^xml-rpc$') {
my($self, $c) = @_;
$c->xmlrpc;
}
sub jsonrpc_endpoint : Regexp('^json-rpc$') {
my($self, $c) = @_;
$c->json_rpc;
}
sub add : Remote {
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/MCP.pm view on Meta::CPAN
+Catalyst::Plugin::JSONRPC::Server
+Catalyst::Plugin::MCP
/;
__PACKAGE__->setup;
# in a controller action mounted at your MCP endpoint
sub mcp :Path('/mcp') :Args(0) {
my ( $self, $c ) = @_;
$c->mcp_register_provider( $c->model('MCP::Resources') );
$c->mcp_register_provider( $c->model('MCP::Tools') );
$c->mcp_dispatch;
lib/Catalyst/Plugin/MCP.pm view on Meta::CPAN
=head1 SECURITY
B<This plugin ships no authentication and no C<Origin> validation, and
C<mcp_dispatch> does not add any.> A C<tools/call> runs your provider's code,
so an endpoint mounted as in the SYNOPSIS executes tools for anyone who can
POST to it. Guarding it is the application's job, and both of these are on you:
=over
=item Authenticate the endpoint
The MCP Streamable HTTP transport says servers SHOULD authenticate connections.
Put your own authentication (a Catalyst authentication plugin, an C<auto>
action, or middleware) in front of C<mcp_dispatch>, and let the request reach it
only once it is authorised. Consider also what a provider is allowed to reach:
the engine does not scope tools or resources to a user.
=item Validate the C<Origin> header
The transport says servers MUST validate C<Origin> on incoming connections, to
stop a browser on another site from driving your endpoint via DNS rebinding.
Check it against an allow-list and reject anything else before dispatching.
=back
Binding to localhost rather than C<0.0.0.0> is worth it for a local server, but
view release on metacpan or search on metacpan
examples/lib/Example/OAuthAS.pm view on Meta::CPAN
store => 'Store', # resolved via $c->model('Store')
signing_key => 'example-authorization-server-signing-key-0123456789',
issuer => 'http://localhost:5000',
resource => 'urn:example:resource',
scopes_supported => [ 'example:read', 'example:write' ],
authorize_endpoint => 'http://localhost:5000/oauth/authorize',
token_endpoint => 'http://localhost:5000/oauth/token',
registration_endpoint => 'http://localhost:5000/oauth/register',
},
);
# The plugin calls this after a valid /authorize request. A real app would render
# a login + consent page; this example auto-consents as a fixed demo user, mints
view release on metacpan or search on metacpan
examples/README.md view on Meta::CPAN
# OAuth2 resource-server example
A minimal Catalyst app that protects a single endpoint, `/api/whoami`, with
`Catalyst::Plugin::OAuth2::ResourceServer`. The client is self-contained: it
mints its own demo bearer token with `Crypt::JWT` (HS256, using the same
signing key configured in the app), so no separate authorization server is
needed to try this out.
view release on metacpan or search on metacpan
t/auth-code-flow-IT/MyProviderApp/app.pl view on Meta::CPAN
# provider server routes
get('/wellknown' => sub {
my $c = shift;
my %url = (
authorization_endpoint => '/authorize',
end_session_endpoint => '/logout',
token_endpoint => '/token',
jwks_uri => '/jwks',
);
$c->render(json => {map { $_ => $url{$_} } keys %url});
});
# get '/authorize' in MyCatalystApp/Controller/Root.pm (ugly but necessary)
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/OpenIDConnect.pm view on Meta::CPAN
},
);
=head1 CREATING THE OPENIDCONNECT CONTROLLER
To enable the OpenIDConnect endpoints, create a controller in your app that extends
the plugin's controller. Create the file C<lib/MyApp/Controller/OpenIDConnect.pm>
(where MyApp is your app's namespace) with the following content:
package MyApp::Controller::OpenIDConnect;
lib/Catalyst/Plugin/OpenIDConnect.pm view on Meta::CPAN
MyApp->setup(...);
Setting up the controller in this way allows you to keep full control over your
routing, and avoid namespace conflicts with ACL and other route-processing plugins.
The plugin's controller will automatically mount the standard OpenID Connect
endpoints (e.g. C</authorize>, C</token>, C</userinfo>) under the C</openidconnect>
path, so you can access them at C</openidconnect/authorize>, etc.
=head1 ROUTES ADDED TO THE APPLICATION
The plugin's controller adds the following routes to the application:
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/PrometheusTiny.pm view on Meta::CPAN
};
my ($prometheus, # instance
$ignore_path_regexp, # set from config
$include_action_labels, # set from config
$metrics_endpoint, # set from config with default
$no_default_controller, # set from config
$request_path # derived from $metrics_endpoint
);
# for testing
sub _clear_prometheus {
undef $prometheus;
lib/Catalyst/Plugin/PrometheusTiny.pm view on Meta::CPAN
$c->config->{'Plugin::PrometheusTiny'} // {}
);
$include_action_labels = $config->{include_action_labels};
$metrics_endpoint = $config->{endpoint};
if ($metrics_endpoint) {
if ( $metrics_endpoint !~ m|^/| ) {
Carp::croak
"Plugin::PrometheusTiny endpoint '$metrics_endpoint' does not begin with '/'";
}
}
else {
$metrics_endpoint = '/metrics';
}
$request_path = $metrics_endpoint;
$request_path =~ s|^/||;
$ignore_path_regexp = $config->{ignore_path_regexp};
if ($ignore_path_regexp) {
$ignore_path_regexp = qr/$ignore_path_regexp/
lib/Catalyst/Plugin/PrometheusTiny.pm view on Meta::CPAN
$class->prometheus;
return
if $class->config->{'Plugin::PrometheusTiny'}{no_default_controller};
# Paranoia, as we're going to eval $metrics_endpoint
if ( $metrics_endpoint =~ s|[^-A-Za-z0-9\._~/]||g ) {
$class->log->warn(
"Plugin::PrometheusTiny unsafe characters removed from endpoint");
}
$class->log->info(
"Plugin::PrometheusTiny metrics endpoint installed at $metrics_endpoint"
);
eval qq|
package Catalyst::Plugin::PrometheusTiny::Controller;
use base 'Catalyst::Controller';
sub begin : Private { }
sub end : Private { }
sub metrics : Path($metrics_endpoint) Args(0) {
my ( \$self, \$c ) = \@_;
my \$res = \$c->res;
\$res->content_type("text/plain");
\$res->output( \$c->prometheus->format );
}
lib/Catalyst/Plugin/PrometheusTiny.pm view on Meta::CPAN
=head1 DESCRIPTION
This plugin integrates L<Prometheus::Tiny::Shared> with your L<Catalyst> app,
providing some default metrics for requests and responses, with the ability
to easily add further metrics to your app. A default controller is included
which makes the metrics available via the configured L</endpoint>, though this
can be disabled if you prefer to add your own controller action.
See L<Prometheus::Tiny> for more details of the kind of metrics supported.
The following metrics are included by default:
lib/Catalyst/Plugin/PrometheusTiny.pm view on Meta::CPAN
Returns the C<Prometheus::Tiny::Shared> instance.
=head1 CONFIGURATION
=head2 endpoint
The endpoint from which metrics are served. Defaults to C</metrics>.
=head2 filename
It is recommended that this is set to a directory on a memory-backed
filesystem. See L<Prometheus::Tiny::Shared/filename> for details and default
lib/Catalyst/Plugin/PrometheusTiny.pm view on Meta::CPAN
=head2 no_default_controller
no_default_controller => 0 # default
If set to a true value then the default L</endpoint> will not be
added, and you will need to add your own controller action for exporting the
metrics. Something like:
package MyApp::Controller::Stats;
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/ResponseFrom.pm view on Meta::CPAN
1;
=head1 NAME
Catalyst::Plugin::ResponseFrom - Use the response of a public endpoint.
=head1 SYNOPSIS
package MyApp;
use Catalyst 'ResponseFrom';
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/Server/JSONRPC.pm view on Meta::CPAN
methodName: hello.world
path : /hello/world
From this point, it will dispatch to '/hello/world' when it exists,
like Catalyst Urls would do. What means: you will be able to set Regexes,
Paths etc on subroutines to define the endpoint.
We discuss these custom JSONRPC attributes below.
When the request is dispatched, we will return $c->stash->{jsonrpc} to the
jsonrpc client, or, when it is not available, it will return $c->stash to
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/Server/XMLRPC.pm view on Meta::CPAN
methodName: hello.world
path : /hello/world
From this point, it will dispatch to '/hello/world' when it exists,
like Catalyst Urls would do. What means: you will be able to set Regexes,
Paths etc on subroutines to define the endpoint.
We discuss these custom XMLRPC attributes below.
When the request is dispatched, we will return $c->stash->{xmlrpc} to the
xmlrpc client, or, when it is not available, it will return $c->stash to
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/Shorten.pm view on Meta::CPAN
$c->shorten_extract; # checks whether the shorten param exists if it does merges the stored params into the request
}
........
sub endpoint :Chained('base') :PathPart('ending') :Args('0') {
my ($self, $c) = @_;
my $str = $c->shorten(); # returns bijection references to an ID in the store.
my $url = $c->shorten(as_uri => 1); # return a url to the current endpoint replacing all params with localhost:300/ending?s=GH
}
-------
use Catalyst qw/
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/URI.pm view on Meta::CPAN
# V2 does its own version of named actions
my %action_hash = %{$c->dispatcher->_action_hash||+{}};
foreach my $key (keys %action_hash) {
if(my ($name) = @{$action_hash{$key}->attributes->{Name}||[]}) {
croak "You can only name endpoint actions on a chain"
if defined$action_hash{$key}->attributes->{CaptureArgs};
croak "Named action '$name' is already defined"
if $c->dispatcher->_action_hash->{"/#$name"};
$c->dispatcher->_action_hash->{"/#$name"} = $action_hash{$key};
}
lib/Catalyst/Plugin/URI.pm view on Meta::CPAN
my $url = $c->uri("#hi");
This allows you to specify the action by its name from any controller. We don't
allow you to use the same name twice, and we also throw an exception if you attempt
to add a name to an intermediate action in a chain of actions (you can only name
an endpoint).
Lastly For ease of use if the first argument is an action object we just pass it
down to 'uri_for'. That way you should be able to use this method for all types
of URL creation.
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/XMLRPC.pm view on Meta::CPAN
=head1 METHODS
=head2 $c->xmlrpc
Call this method from a controller action to set it up as a endpoint.
=cut
sub xmlrpc {
my $c = shift;
view release on metacpan or search on metacpan
lib/Catalyst/Controller.pm view on Meta::CPAN
base => { Chained => '/', PathPart => '', CaptureArgs => 0 },
},
);
In the case above every sub in the package would be made into a Chain
endpoint with a URI the same as the sub name for each sub, chained
to the sub named C<base>. Ergo dispatch to C</example> would call the
C<base> method, then the C<example> method.
=head2 action_args
lib/Catalyst/Controller.pm view on Meta::CPAN
See L<Catalyst::ActionRole::ConsumesContent> for more.
=head2 Scheme(...)
Allows you to specify a URI scheme for the action or action chain. For example
you can required that a given path be C<https> or that it is a websocket endpoint
C<ws> or C<wss>. For an action chain you may currently only have one defined
Scheme.
package MyApp::Controller::Root;
view release on metacpan or search on metacpan
lib/Catalyst/TraitFor/Request/ProxyBase.pm view on Meta::CPAN
server what the original URI for the request was, or if the request was
initially SSL. (Yes, I do know about C<< X-Forwarded-Host >>, but they don't
do enough)
This creates an issue for someone wanting to deploy the same cluster of
application servers behind various URI endpoints.
Using this module, the request base (C<< $c->req->base >>)
is replaced with the contents of the C<< X-Request-Base >> header,
which is expected to be a full URI, for example:
view release on metacpan or search on metacpan
lib/Catalyst/View/JSON/PerRequest.pm view on Meta::CPAN
sub midpoint :Chained(root) CaptureArgs(0) {
my ($self, $c) = @_;
$c->view('JSON')->data->set(y=>1);
}
sub endpoint :Chained(midpoint) Args(0) {
my ($self, $c) = @_;
$c->view('JSON')->created({
a => 1,
b => 2,
c => 3,
view release on metacpan or search on metacpan
lib/Catalyst/View/TT/Progressive.pm view on Meta::CPAN
};
...
})();
when using this approach you may want to prevent accessing of endpoints directly from a browser an easy way of achieving this is checking for a header in Root->auto and then redirecting.
unless ($c->req->header('api')) {
$c->response->redirect($c->uri_for('/invalid_url'));
return;
}
view release on metacpan or search on metacpan
lib/Catalyst/View/Text/MicroTemplate/PerRequest.pm view on Meta::CPAN
sub midpoint :Chained(root) CaptureArgs(0) {
my ($self, $c) = @_;
$c->view('HTML')->data->set(y=>1);
}
sub endpoint :Chained(midpoint) Args(0) {
my ($self, $c) = @_;
$c->view('JSON')->created({
a => 1,
b => 2,
c => 3,
});
}
# template $HOME/root/endpoint.mt
This is my template
Here's some placeholders
a => <?= $a ?>
b => <?= $b ?>
view release on metacpan or search on metacpan
lib/CatalystX/Crudite/Util/Random.pm view on Meta::CPAN
endowed
endowing
endowment
endowments
endows
endpoint
ends
endurable
endurably
endurance
endure
view release on metacpan or search on metacpan
lib/CatalystX/Declare/Keyword/Action.pm view on Meta::CPAN
if $what eq 'private';
return sub {
my $method = shift;
if ($what eq any qw( end endpoint final )) {
$attrs->{Args} = delete $attrs->{CaptureArgs};
}
elsif ($what eq 'private') {
$attrs->{Private} = [];
}
lib/CatalystX/Declare/Keyword/Action.pm view on Meta::CPAN
# you can use a shortcut for multiple actions with
# a common base
under base {
# this is an endpoint after base
action normal is final;
# the final keyword can be used to be more
# visually explicit about end-points
final action some_action { ... }
view release on metacpan or search on metacpan
lib/CatalystX/ExtJS/Tutorial/Direct.pm view on Meta::CPAN
$c->res->content_type('application/json');
$c->res->body(encode_json($c->req->data));
}
As you can see the C<add_to> action has the C<Direct> attribute attached
to it. Direct actions can only be attached to endpoints of Chained actions.
By default the method's name for the API is the same as the action's
name. In this case however we changed the name of the action to C<add> by
adding this as parameter to the C<Direct> attribute.
If you add the Direct attribute to a normal action (e.g. C<Local>)
it has no arguments by default. To change that you can add the C<DirectArgs>
attribute and enter the number of arguments there. If you add C<DirectArgs>
to a Chained endpoint the number of arguments will be added to the number
of arguments required to call this endpoint.
The C<echo> action accepts one argument from the Direct API. You can access this argument
via C<< $c->req->data >>, which is always an arrayref and includes all arguments.
We set the content type to C<application/json> to make sure that the
body is not serialized twice. That is, if you would not set the content type,
view release on metacpan or search on metacpan
lib/CatalystX/Action/ExtJS/REST.pm view on Meta::CPAN
#
# The (three-clause) BSD License
#
package CatalystX::Action::ExtJS::REST;
$CatalystX::Action::ExtJS::REST::VERSION = '2.1.3';
# ABSTRACT: Mark an action as REST endpoint
use Moose;
extends 'Catalyst::Action';
1;
lib/CatalystX/Action/ExtJS/REST.pm view on Meta::CPAN
=encoding UTF-8
=head1 NAME
CatalystX::Action::ExtJS::REST - Mark an action as REST endpoint
=head1 VERSION
version 2.1.3
=head1 DESCRIPTION
The purpose of this action class is to mark an action as REST endpoint.
Actions with this action will become a L<CatalystX::Controller::ExtJS::Direct::Route::REST> route.
=head1 AUTHOR
Moritz Onken <onken@netcubed.de>
view release on metacpan or search on metacpan
lib/CatalystX/OAuth2/Provider/Controller/OAuth.pm view on Meta::CPAN
my ( $self, $ctx, $grant_type ) = @_;
}
=head2 authorize
Authorize endpoint
=cut
sub authorize
:Chained('logged_in_required')
:PathPart('authorize') #Configurable?
:Args(0)
{
my ( $self, $ctx ) = @_;
if ( $ctx->req->method eq 'GET' ) {
$ctx->stash( authorize_endpoint => $ctx->uri_for_action($ctx->action) );
$ctx->stash( template => $self->{authorize_form}->{template}
|| 'oauth/authorize.tt' );
}
if ( $ctx->req->method eq 'POST' ) {
view release on metacpan or search on metacpan
lib/Catalyst/ActionRole/OAuth2/AuthToken/ViaAuthGrant.pm view on Meta::CPAN
package Catalyst::ActionRole::OAuth2::AuthToken::ViaAuthGrant;
use Moose::Role;
use Try::Tiny;
use CatalystX::OAuth2::Request::AuthToken;
# ABSTRACT: Authorization token provider endpoint for OAuth2 authentication flows
with 'CatalystX::OAuth2::ActionRole::Token';
sub build_oauth2_request {
lib/Catalyst/ActionRole/OAuth2/AuthToken/ViaAuthGrant.pm view on Meta::CPAN
=pod
=head1 NAME
Catalyst::ActionRole::OAuth2::AuthToken::ViaAuthGrant - Authorization token provider endpoint for OAuth2 authentication flows
=head1 VERSION
version 0.001009
lib/Catalyst/ActionRole/OAuth2/AuthToken/ViaAuthGrant.pm view on Meta::CPAN
1;
=head1 DESCRIPTION
This action role implements an endpoint that exchanges an authorization code
for an access token.
=head1 AUTHOR
Eden Cardim <edencardim@gmail.com>
view release on metacpan or search on metacpan
lib/Catalyst/ActionRole/RequestModel.pm view on Meta::CPAN
}
The main reason for moving this into the action attributes line is the thought that it allows us
to declare the request model as meta data on the action and in the future we will be able to
introspect that meta data at application setup time to do things like generate an Open API specification.
Also, if you have several request models for the endpoint you can declare all of them on the
attributes line and we will match the incoming request to the best request model, or throw an exception
if none match. So if you have more than one this saves you writing that boilerplate code to chose and
to handled the no match conditions.
You might also just find the code neater and more clean reading. Downside is for people unfamiliar with
view release on metacpan or search on metacpan
lib/Catmandu/AAT.pm view on Meta::CPAN
Catmandu::AAT - Retrieve items from the AAT
=head1 SYNOPSIS
This module contains a L<store|Catmandu::Store::AAT> to lookup a I<Subject> in the L<AAT|https://www.getty.edu/research/tools/vocabularies/aat/>
using its L<SPARQL endpoint|http://vocab.getty.edu/sparql>.
Also included is a L<fix|Catmandu::Fix::aat_match> to match a term to a I<Subject> and a
L<fix|Catmandu::Fix::aat_search> to search for a term in the AAT.
lookup_in_store(objectName, AAT, lang:nl)