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 the
   PlRPC::Client(3) manpage and the RPC::PlServer::Comm manpage 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.

 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 the Net::Daemon(3) manpage 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 the section on
   "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. the MD5(3) manpage. We present the server
   source here, the client is part of the RPC::PlClient man page.
   See the RPC::PlClient(3) manpage.

       #!/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(Net::Daemon);

       eval {
           # Server options below can be overwritten in the config file or
           # on the command line.
           my $server = RPC::PlServer->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
                       },
                   '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 ...)

   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.

   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 the section on "/CONFIGURATION FILE".

   User based authorization
       PlRPC has a builtin user based authorization scheme; use it!
       See the section on "/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.

AUTHOR AND COPYRIGHT
   The PlRPC-modules are

     Copyright (C) 1998, Jochen Wiedmann
                         Am Eisteich 9
                         72555 Metzingen
                         Germany

                         Phone: +49 7123 14887
                         Email: [email protected]

     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
   the RPC::PlClient(3) manpage, the RPC::PlServer::Comm(3)
   manpage, the Net::Daemon(3) manpage, the Net::Daemon::Log(3)
   manpage, the Storable(3) manpage, the Sys::Syslog(3) manpage,
   the Win32::EventLog(3) manpage

   See the DBI::ProxyServer(3) manpage for an example application.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.