Acme-ReturnValue

 view release on metacpan or  search on metacpan

t/pms/Envolve.pm  view on Meta::CPAN

use Digest::HMAC_SHA1 qw(hmac_sha1_hex);
use Encode qw(encode);

has api_key => (
    is          => 'ro',
    required    => 1,
    trigger     => sub {
        my ($self, $value) = @_;
        confess 'EnvolveAPI: Invalid API Key' unless $value =~ m/\d+-\w+/;
        my @key_parts = split /-/, $self->api_key;
        $self->secret($key_parts[1]);
        $self->site_id($key_parts[0]);
    }
);

has secret  => (
    is          => 'rw',
);

has site_id => (
    is          => 'rw',
);

sub get_tags {
    my ($self, $first_name, %options) = @_;
    my $command = ($first_name) ? $self->get_login_command($first_name, %options) : $self->get_logout_command;

t/pms/Envolve.pm  view on Meta::CPAN

    foreach my $key (keys %params) {
        my $value = ($key eq 'admin') ? $params{$key} : encode_base64url(encode("UTF-8",$params{$key}));
        $command_string .= ',' . $key . '=' . $value; 
        chomp $command_string;
    }
    return $command_string;
}

sub sign_command_string {
    my ($self, $command_string) = @_;
    my $hash = hmac_sha1_hex( $command_string, $self->secret);
    return $hash . ';' . $command_string;
}

no Any::Moose;
__PACKAGE__->meta->make_immutable;


=head1 NAME

Chat::Envolve - A Perl API for the Envolve web chat system.

t/pms/RayApp.pm  view on Meta::CPAN

and tests for both application and presentation part can be written
independently, in parallel. Of course, this also works if you are the
sole person on the project, playing the above mentioned roles.

The system will never produce unexpected data output, since the data
output is based on DSD which is known.

=head1 CONFIGURATION

Most of the use of RayApp is expected in the Web context. This
section summarizes configuration steps needed for the Apache HTTP
server. This version of RayApp works with Apache 2.0
and mod_perl 2.0.

Assume you have a Web application that should reside on URL

	http://server/sub/app.html

The application consists of three files:

	/opt/www/app.dsd

t/pms/RayApp.pm  view on Meta::CPAN

be processed by B<usr/bin/rayapp_cgi_wrapper>, and the
C<SetEnv RAYAPP_DIRECTORY> tells B<RayApp> where on the filesystem
should it find the necessary files of the application (the same
as B<Alias> with mod_perl setup).
Here we partly simulate the work that Apache would have done for us
in the static files case.

Both B<LocationMatch> in mod_perl case and B<Location> in CGI case can
of course contain additional configuration options for Apache,
like B<Order> / B<Allow>, and configuration of B<RayApp>, described
in the next section.

=head2 More detailed setup

For mod_perl, the configuration is done using B<PerlSetVar> and the
variable name in in mixed capitals. For CGI, enviroment variables are
used, set using B<SetEnv> and the variable name is in all capitals,
words separated by underscores. For example, for mod_perl the directive
would be

	PerlSetVar RayAppDirectoryIndex index.html

t/pms/RayApp.pm  view on Meta::CPAN

context -- all of them want to be passed an open B<$dbh> database
handler (instead of doing their own DBI->connect), all of them want to
be passed the request object to query the input parameters.

The option B<RayAppInputModule> specifies a module name which will
be loaded and from which a B<handler> function will be called for
every request. The function should return a list of values that
will be passed in as parameters to the application B<handler>.

The first parameter passed to this input module B<handler> is the
B<RayApp::DSD> object, for mod_perl the second argument is the request
(B<Apache2::RequestRec>) object. An example of an input module might
be

	package Application::Input;

	use RayApp::Request ();
	use DBI ();
	sub handler {
		my ($dsd, $r) = @_;
		if (defined $dsd) {