RPC::PlServer(category11-mail-server.html) - phpMan

RPC::PlServer(3)      User Contributed Perl Documentation     RPC::PlServer(3)

NAME
       RPC::PlServer - Perl extension for writing PlRPC servers
SYNOPSIS
         # Create a subclass of RPC::PlServer
         use RPC::PlServer;
         package MyServer;
         $MyServer::VERSION = '0.01';
         @MyServer::ISA = qw(RPC::PlServer);
         # Overwrite the Run() method to handle a single connection
         sub Run {
             my $self = shift;
             my $socket = $self->{'socket'};
         }
         # Create an instance of the MyServer class
         package main;
         my $server = MyServer->new({'localport' => '1234'}, \@ARGV);
         # Bind the server to its port to make it actually running
         $server->Bind();
DESCRIPTION
       PlRPC (Perl RPC) is a package for implementing servers and clients that
       are written in Perl entirely. The name is borrowed from Sun's RPC
       (Remote Procedure Call), but it could as well be RMI like Java's
       "Remote Method Interface), because PlRPC gives you the complete power
       of Perl's OO framework in a very simple manner.
       RPC::PlServer is the package used on the server side, and you guess
       what RPC::PlClient is for. Both share the package RPC::PlServer::Comm
       for communication purposes. See PlRPC::Client(3) and
       RPC::PlServer::Comm for these parts.
       PlRPC works by defining a set of methods that may be executed by the
       client.  For example, the server might offer a method "multiply" to the
       client. Now the clients method call
           @result = $client->multiply($a, $b);
       will be immediately mapped to a method call
           @result = $server->multiply($a, $b);
       on the server. The arguments and results will be transferred to or from
       the server automagically. (This magic has a name in Perl: It's the
       Storable module, my thanks to Raphael Manfredi for this excellent
       package.) Simple, eh? :-)
       The RPC::PlServer and RPC::PlClient are abstract servers and clients:
       You have to derive your own classes from it.
   Additional options
       The RPC::PlServer inherits all of Net::Daemon's options and attributes
       and adds the following:
       cipher  The attribute value is an instance of Crypt::DES, Crypt::IDEA
               or any other class with the same API for block encryption. If
               you supply such an attribute, the traffic between client and
               server will be encrypted using this option.
       maxmessage (--maxmessage=size)
               The size of messages exchanged between client and server is
               restricted, in order to omit denial of service attacks. By
               default the limit is 65536 bytes.
       users   This is an attribute of the client object used for Permit/Deny
               rules in the config file. It's value is an array ref of user
               names that are allowed to connect from the given client. See
               the example config file below. "CONFIGURATION FILE".
   Error Handling
       Error handling is simple with the RPC package, because it is based on
       Perl exceptions completely. Thus your typical code looks like this:
         eval {
             # Do something here. Don't care for errors.
             ...
         };
         if ($@) {
             # An error occurred.
             ...
         }
   Server Constructors
         my $server = RPC::PlServer(\%options, \@args);
       (Class method) This constructor is immediately inherited from the
       Net::Daemon package. See Net::Daemon(3) for details.
   Access Control
         $ok = $self->AcceptApplication($app);
         $ok = $self->AcceptVersion($version);
         $ok = $self->AcceptUser($user, $password);
       The RPC::PlServer package has a very detailed access control scheme:
       First of all it inherits Net::Daemon's host based access control. It
       adds version control and user authorization. To achieve that, the
       method Accept from Net::Daemon is split into three methods,
       AcceptApplication, AcceptVersion and AcceptUser, each of them returning
       TRUE or FALSE. The client receives the arguments as the attributes
       application, version, user and password. A client is accepted only if
       all of the above methods are returning TRUE.
       The default implementations are as follows: The AcceptApplication
       method returns TRUE, if $self is a subclass of $app. The AcceptVersion
       method returns TRUE, if the requested version is less or equal to
       ${$class}::VERSION, $self being an instance of $class. Whether a user
       is permitted to connect depends on the client configuration. See
       "CONFIGURATION FILE" below for examples.
   Method based access control
       Giving a client the ability to invoke arbitrary methods can be a
       terrible security hole. Thus the server has a methods attribute. This
       is a hash ref of class names as keys, the values being hash refs again
       with method names as the keys. That is, if your hash looks as follows:
           $self->{'methods'} = {
               'CalcServer' => {
                   'NewHandle' => 1,
                   'CallMethod' => 1 },
               'Calculator' => {
                   'new' => 1,
                   'multiply' => 1,
                   'add' => 1,
                   'divide' => 1,
                   'subtract' => 1 }
               };
       then the client may use the CalcServer's NewHandle method to create
       objects, but only via the permitted constructor Calculator->new. Once a
       Calculator object is created, the server may invoke the methods
       multiply, add, divide and subtract.
CONFIGURATION FILE
       The server config file is inherited from Net::Daemon. It adds the users
       and cipher attribute to the client list. Thus a typical config file
       might look as follows:
           # Load external modules; this is not required unless you use
           # the chroot() option.
           #require DBD::mysql;
           #require DBD::CSV;
           # Create keys
           my $myhost_key = Crypt::IDEA->new('83fbd23390ade239');
           my $bob_key    = Crypt::IDEA->new('be39893df23f98a2');
           {
               # 'chroot' => '/var/dbiproxy',
               'facility' => 'daemon',
               'pidfile' => '/var/dbiproxy/dbiproxy.pid',
               'user' => 'nobody',
               'group' => 'nobody',
               'localport' => '1003',
               'mode' => 'fork',
               # Access control
               'clients' => [
                   # Accept the local LAN (192.168.1.*)
                   {
                       'mask' => '^192\.168\.1\.\d+$',
                       'accept' => 1,
                       'users' => [ 'bob', 'jim' ],
                       'cipher' => $myhost_key
                   },
                   # Accept myhost.company.com
                   {
                       'mask' => '^myhost\.company\.com$',
                       'accept' => 1,
                       'users' => [ {
                           'name' => 'bob',
                           'cipher' => $bob_key
                           } ]
                   },
                   # Deny everything else
                   {
                       'mask' => '.*',
                       'accept' => 0
                   }
               ]
           }
       Things you should note: The user list of 192.168.1.* contains scalar
       values, but the user list of myhost.company.com contains hash refs:
       This is required, because the user configuration is more specific for
       user based encryption.
EXAMPLE
       Enough wasted time, spread the example, not the word. :-) Let's write a
       simple server, say a server for MD5 digests. The server uses the
       external package MD5, but the client doesn't need to install the
       package. MD5(3). We present the server source here, the client is part
       of the RPC::PlClient man page. See RPC::PlClient(3).
           #!/usr/bin/perl -wT
           # Note the -T switch! This is always recommended for Perl servers.
           use strict;               # Always a good choice.
           require RPC::PlServer;
           require MD5;

           package MD5_Server;  # Clients need to request application
                                # "MD5_Server"
           $MD5_Server::VERSION = '1.0'; # Clients will be refused, if they
                                         # request version 1.1
           @MD5_Server::ISA = qw(RPC::PlServer);
           eval {
               # Server options below can be overwritten in the config file or
               # on the command line.
               my $server = MD5_Server->new({
                   'pidfile'    => '/var/run/md5serv.pid',
                   'configfile' => '/etc/md5serv.conf',
                   'facility'   => 'daemon', # Default
                   'user'       => 'nobody',
                   'group'      => 'nobody',
                   'localport'  => 2000,
                   'logfile'    => 0,        # Use syslog
                   'mode'       => 'fork',   # Recommended for Unix
                   'methods'    => {
                       'MD5_Server' => {
                           'ClientObject' => 1,
                           'CallMethod' => 1,
                           'NewHandle' => 1
                           },
                       'MD5' => {
                           'new' => 1,
                           'add' => 1,
                           'hexdigest' => 1
                           },
                       }
               });
               $server->Bind();
           };
SECURITY
       It has to be said: PlRPC based servers are a potential security
       problem!  I did my best to avoid security problems, but it is more than
       likely, that I missed something. Security was a design goal, but not
       *the* design goal. (A well known problem ...)
       Due to implementation of PlRPC, it's hard to use internal
       authentication mechanisms properly to achieve secured remote calls.
       Therefore users are advised to use an external authentication mechanism
       like TLS or IPsec.
       I highly recommend the following design principles:
   Protection against "trusted" users
       perlsec
           Read the perl security FAQ ("perldoc perlsec") and use the "-T"
           switch.
       taintperl
           Use the "-T" switch. I mean it!
       Verify data
           Never untaint strings withouth verification, better verify twice.
           For example the CallMethod function first checks, whether an object
           handle is valid before coercing a method on it.
       Be restrictive
           Think twice, before you give a client access to a method.
       Use of Storable
           Storable module used for serialization and deserialization
           underneath is inherently insecure. Deserialized data can contain
           objects which lead to loading foreign modules and executing
           possible attached destructors. Do not accept host-based
           unauthorized connections. The Storable module is exercised before
           checking user password.
       perlsec
           And just in case I forgot it: Read the "perlsec" man page. :-)
   Protection against untrusted users
       Host based authorization
           PlRPC has a builtin host based authorization scheme; use it!  See
           "CONFIGURATION FILE".
       User based authorization
           PlRPC has a builtin user based authorization scheme; use it!  See
           "CONFIGURATION FILE".
       Encryption
           Using encryption with PlRPC is extremely easy. There is absolutely
           no reason for communicating unencrypted with the clients. Even
           more: I recommend two phase encryption: The first phase is the
           login phase, where to use a host based key. As soon as the user has
           authorized, you should switch to a user based key. See the
           DBI::ProxyServer for an example.
           Please note PlRPC encryption does not protect from reply attacks.
           You should have implement it on the application or the cipher
           level.
AUTHOR AND COPYRIGHT
       The PlRPC-modules are
         Copyright (C) 1998, Jochen Wiedmann
                             Email: jochen.wiedmann at freenet.de
         All rights reserved.
       You may distribute this package under the terms of either the GNU
       General Public License or the Artistic License, as specified in the
       Perl README file.
SEE ALSO
       RPC::PlClient(3), RPC::PlServer::Comm(3), Net::Daemon(3),
       Net::Daemon::Log(3), Storable(3), Sys::Syslog(3), Win32::EventLog(3)
       See DBI::ProxyServer(3) for an example application.

perl v5.16.3                      2014-06-10                  RPC::PlServer(3)