.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.if !\nF .nr F 0
.if \nF>0 \{\
.    de IX
.    tm Index:\\$1\t\\n%\t"\\$2"
..
.    if !\nF==2 \{\
.        nr % 0
.        nr F 2
.    \}
.\}
.\" ========================================================================
.\"
.IX Title "RPC::pServer 3pm"
.TH RPC::pServer 3pm "2018-07-08" "perl v5.26.2" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
RPC::pServer \- Perl extension for writing pRPC servers
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\&  use RPC::pServer;
\& 
\&  $sock = IO::Socket::INET\->new(\*(AqLocalPort\*(Aq => 9000,
\&                                \*(AqProto\*(Aq => \*(Aqtcp\*(Aq,
\&                                \*(AqListen\*(Aq = 5,
\&                                \*(AqReuse\*(Aq => 1);
\&
\&  $connection = new RPC::pServer(\*(Aqsock\*(Aq => $sock,
\&                                      \*(AqconfigFile\*(Aq => $file,
\&                                      \*(AqfuncTable\*(Aq => $funcTableRef,
\&                                      # other attributes #
\&                                     );
\&
\&  while ($running) {
\&      $connection\->Loop();
\&      if ($connection\->error) {
\&          # Do something
\&      }
\&  }
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
pRPC (Perl \s-1RPC\s0) is a package that simplifies the writing of Perl based
client/server applications. RPC::pServer is the package used on the
server side, and you guess what Net::pRPC::Client is for. See
\&\fINet::pRPC::Client\fR\|(3) for this part.
.PP
pRPC works by defining a set of of functions that may be executed by
the client. For example, the server might offer a function \*(L"multiply\*(R"
to the client. Now a function call
.PP
.Vb 1
\&    @result = $con\->Call(\*(Aqmultiply\*(Aq, $a, $b);
.Ve
.PP
on the client will be mapped to a corresponding call
.PP
.Vb 1
\&    multiply($con, $data, $a, $b);
.Ve
.PP
on the server. (See the \fIfuncTable\fR description below for
\&\f(CW$data\fR.) The function call's result will be returned to the
client and stored in the array \f(CW@result\fR. Simple, eh? :\-)
.SS "Server methods"
.IX Subsection "Server methods"
.IP "new" 4
.IX Item "new"
The server constructor. Unlike the usual constructors, this one
will in general not return immediately, at least not for a
server running as a daemon. Instead it will return if a
connection is established with a connection object as result.
The result will be an error string or the connection object,
thus you will typically do a
.Sp
.Vb 7
\&    $con = RPC::pServer\->new ( ...);
\&    if (!ref($con)) {
\&        print "Error $con.\en";
\&    } else {
\&        # Accept connection
\&        ...
\&    }
.Ve
.IP "Accept" 4
.IX Item "Accept"
.PD 0
.IP "Deny" 4
.IX Item "Deny"
.PD
After a connection is established, the server should call either of
these methods. If he calls \fIAccept()\fR, he should continue with calling
the \fILoop()\fR method for processing the clients requests.
.IP "Loop" 4
.IX Item "Loop"
When a connection is established, the Loop method must be called. It
will process the client's requests. If \fILoop()\fR returns \s-1FALSE,\s0 an error
occurred. It is the main programs task to decide what to do in that
case.
.IP "Encrypt" 4
.IX Item "Encrypt"
This method can be used to get or set the \fIcipher\fR attribute, thus
the encryption mode. If the method is passed an argument, the argument
will be used as the new encryption mode. ('undef' for no encryption.)
In either case the current encryption mode will be returned. Example:
.Sp
.Vb 2
\&    # Get the current encryption mode
\&    $mode = $server\->Encrypt();
\&
\&    # Currently disable encryption
\&    $server\->Encrypt(undef);
\&
\&    # Switch back to the old mode
\&    $server\->Encrypt($mode);
.Ve
.SS "Server attributes"
.IX Subsection "Server attributes"
Server attributes will typically be supplied with the \f(CW\*(C`new\*(C'\fR
constructor.
.IP "configFile" 4
.IX Item "configFile"
RPC::pServer has a builtin authorization mechanism based on
a configuration file. If you want to use this mechanism,
just supply the name of a configuration file with the attribute
configFile and the server will accept or deny connections
based on the configuration file.
.Sp
The authorization scheme is host based, but you may add
user based functionality with the user and password
attributes. See \*(L"\s-1CONFIGURATION FILE\*(R"\s0 below.
.IP "client" 4
.IX Item "client"
This attribute is useful in conjunction with the \fIconfigFile\fR.
If the server has authorized a client by using the config file,
he will create a hash ref with all the client attributes
and store a reference to this hash under the key \fIclient\fR.
Thus you can easily extend the configuration file for your
own purposes, at least as long as host based configuration is
sufficient for you.
.IP "sock" 4
.IX Item "sock"
An object of type IO::Socket, if this program is running
as a daemon. An \fIaccept()\fR call will be executed on this
socket in order to wait for connections. See \fIIO::Socket\fR\|(3).
.Sp
An inetd based server should leave this attribute empty:
The method will use \s-1STDIN\s0 and \s-1STDOUT\s0 instead.
.Sp
\&\fBNote:\fR The latter is not yet functionable, I first need
to work out how to create an object of type IO::socket for
an inetd based server's \s-1STDIN\s0 and \s-1STDOUT.\s0 It seems this
is currently not supported by IO::Socket.
.IP "cipher" 4
.IX Item "cipher"
This attribute can be used to add encryption quite easily. pRPC is not
bound to a certain encryption method, but to a block encryption \s-1API.\s0 The
attribute is an object supporting the methods \fIblocksize\fR, \fIencrypt\fR
and \fIdecrypt\fR. For example, the modules Crypt::DES and Crypt::IDEA
support such an interface.
.Sp
Do \fBnot\fR modify this attribute directly, use the \fIencrypt\fR method
instead!  However, it is legal to pass the attribute to the constructor.
.Sp
Example:
.Sp
.Vb 3
\&    use Crypt::DES;
\&    $crypt = DES\->new(pack("H*", "0123456789abcdef"));
\&    $client\->Encrypt($crypt);
\&
\&    # or, to stop encryption
\&    $client\->Encrypt(undef);
.Ve
.Sp
You might prefer encryption being client dependent, so there is the
additional possibility to setup encryption in the server configuration
file. See \*(L"\s-1CONFIGURATION FILE\*(R"\s0. Client encryption definitions take
precedence over the \fIcipher\fR attribute.
.Sp
However, you can set or remove encryption on the fly (putting \f(CW\*(C`undef\*(C'\fR
as attribute value will stop encryption), but you have to be sure,
that both sides change the encryption mode.
.IP "funcTable" 4
.IX Item "funcTable"
This attribute is a hash reference. The hash keys are the
names of methods, that the client may execute on the server.
The hash values are hash references (again). The RPC::pServer
module will use the key 'code' only: It contains a code reference
to the function performing the clients function call. The first
argument of the function call will be the connection object
itself, the second will be the 'funcTable' value. You are free
to use this hash reference in any way you want, the exception
being the 'code' key. The function must return a list: In case
of errors the results will be the values 0, followed by a
textual error message. In case of success, it ought to return
nonzero, followed by the result list being sent to the client.
.IP "stderr" 4
.IX Item "stderr"
a value of \s-1TRUE\s0 will enable logging messages to \s-1STDERR,\s0 the
default is using \fIsyslog()\fR; if the stderr attribute is \s-1FALSE,\s0
you might call \fIopenlog()\fR to configure the application name
and facility. See \fISys::Syslog\fR\|(3).
.IP "debug" 4
.IX Item "debug"
this will cause the server to log debugging information
about client requests using the \fILog\fR method. A value
of 0 disables debugging.
.IP "application" 4
.IX Item "application"
.PD 0
.IP "version" 4
.IX Item "version"
.IP "user" 4
.IX Item "user"
.IP "password" 4
.IX Item "password"
.PD
it is part of the pRPC authorization process, that the client
must obeye a login procedure where he will pass an application
name, a protocol version and optionally a user name and password.
These are not used by pRPC, but when the new method returns with
a connection object, the main program may use these for additional
authorization.
.Sp
These attributes are read-only.
.IP "io" 4
.IX Item "io"
this attribute is a Storable object created for communication
with the client. You may use this, for example, when you want to
change the encryption mode with \fIStorable::Encrypt()\fR. See
\&\fIStorable\fR\|(3).
.SH "CONFIGURATION FILE"
.IX Header "CONFIGURATION FILE"
The server configuration file is currently not much more than a
collection of client names or ip numbers that should be permitted
or denied to connect to the server. Any client is represented by
a definition like the following:
.PP
.Vb 4
\&        accept .*\e.neckar\-alb\e.de
\&            encryption    DES
\&            key           063fde7982defabc
\&            encryptModule Crypt::DES
\&
\&        deny .*
.Ve
.PP
In other words a client definition begins with either \f(CW\*(C`accept pattern\*(C'\fR
or \f(CW\*(C`deny pattern\*(C'\fR, followed by some client attributes, each of the
attributes being on a separate line, followed by the attribute value.
The \f(CW\*(C`pattern\*(C'\fR is a perl regular expression matching either the
clients host name or \s-1IP\s0 number. In particular this means that you
have to escape dots, for example a client with \s-1IP\s0 number
194.77.118.1 is represented by the pattern \f(CW\*(C`194\e.77\e.118\e.1\*(C'\fR.
.PP
Currently known attributes are:
.IP "encryption" 4
.IX Item "encryption"
.PD 0
.IP "key" 4
.IX Item "key"
.IP "encryptionModule" 4
.IX Item "encryptionModule"
.PD
These will be used for creating an encryption object which is used
for communication with the client, see \fIStorable\fR\|(3) for
details. The object is created with a sequence like
.Sp
.Vb 2
\&        use $encryptionModule;
\&        $cipher = $encryption\->new(pack("H*", $key));
.Ve
.Sp
\&\fIencryptionModule\fR defaults to \fIencryption\fR, the reason why we need
both is the brain damaged design of the Crypt::IDEA and Crypt::DES
modules, which use different module and package names without any
obvious reason.
.PP
You may add any other attribute you want, thus extending your authorization
file. The RPC::pServer module will simply ignore them, but your main
program will find them in the \fIclient\fR attribute of the RPC::pServer
object. This can be used for additional client dependent configuration.
.SH "PREDEFINED FUNCTIONS"
.IX Header "PREDEFINED FUNCTIONS"
RPC::pServer offers some predefined methods which are designed
for ease in work with objects. In short they allow creation of
objects on the server, passing handles to the client and working
with these handles in a fashion similar to the use of the true
objects.
.PP
The handle functions need to share some common data, namely a hash
array of object handles (keys) and objects (values). The problem
is, how to allocate these variables. By keeping a multithreaded
environment in mind, we suggest to store the hash on the stack
of the server's main loop.
.PP
The handle functions get access to this loop, by looking into
the 'handles' attribute of the respective entry in the
\&'funcTables' hash. See above for a description of the
\&'funcTables' hash.
.PP
See below for an example of using the handle functions.
.IP "NewHandle" 4
.IX Item "NewHandle"
This method can be inserted into the servers function table. The
client may call this function to create objects and receive handles
to the objects. The corresponding entry in the function table 
must have a key \fIclasses\fR: This is a list reference with
class names. The client is restricted to create objects of these
classes only.
.Sp
The \fINewHandle\fR function expects, that the constructor returns
an object in case of success or 'undef' otherwise. Note, that
this isn't true in all cases, for example the RPC::pServer
and Net::pRPC::Client classes behave different. In that cases
you have to write your own constructor with a special error
handling. The \fIStoreHandle\fR method below will help you.
Constructors with a different name than \fInew\fR are another
example when you need \fIStoreHandle\fR directly.
.IP "StoreHandle" 4
.IX Item "StoreHandle"
After you have created an object on behave of the clients request,
you'd like to store it for later use. This is what \fIStoreHandle\fR
does for you. It returns an object handle which may be passed back
to the client. The client can pass the objects back to the server
for use in \fICallMethod\fR or \fIUseHandle\fR.
.IP "NewHandle" 4
.IX Item "NewHandle"
The \fINewHandle\fR is mainly a wrapper for \fIStoreHandle\fR. It creates
an object of the given class, passes it to \fIStoreHandle\fR and returns
the result. The \fINewHandle\fR method is designed for direct use
within the servers function table.
.IP "UseHandle" 4
.IX Item "UseHandle"
This is the counterpart of \fIStoreHandle\fR: It gets an object handle,
passed by the client, as argument and returns the corresponding
object, if any. An 'undef' value will be returned for an invalid
handle.
.IP "CallMethod" 4
.IX Item "CallMethod"
This function receives an object handle as argument and the name
of a method being executed. The method will be invoked on the
corresponding object and the result will be returned.
.Sp
A special method is '\s-1DESTROY\s0', valid for any object handle. It
disposes the object, the handle becomes invalid.
.PP
All handle functions are demonstrated in the following example.
.SH "EXAMPLE"
.IX Header "EXAMPLE"
Enough wasted time, spread the example, not the word. :\-) Let's write
a simple server, say a spreadsheet server. Of course we are not
interested in the details of the spreadsheet part (which could well
be implemented in a separate program), the spreadsheet example
is chosen, because it is obvious, that such a server is dealing
with complex data structures. For example, a \*(L"sum\*(R" method should
be able to add over complete rows, columns or even rectangular
regions of the spreadsheet. And another thing, obviously a spread\-
sheet could easily be represented by perl data structures:
The spreadsheet itself could be a list of lists, the elements
of the latter lists being hash references, each describing one
column. You see, such a spreadsheet is an ideal object for
the \fIStorable\fR\|(3) class. But now, for something completely
different:
.PP
.Vb 3
\&    #!/usr/local/bin/perl \-wT # Note the \-T switch! I mean it!
\&    use 5.0004;               # Yes, this really *is* required.
\&    use strict;               # Always a good choice.
\&
\&    use IO::Socket();
\&    use RPC::pServer;
\&
\&    # Constants
\&    $MY_APPLICATION = "Test Application";
\&    $MY_VERSION = 1.0;
\&
\&    # Functions that the clients may execute; for simplicity
\&    # these aren\*(Aqt designed in an object oriented manner.
\&
\&    # Function returning a simple scalar
\&    sub sum ($$$$$) {
\&        my($con, $data, $spreadsheet, $from, $to) = @_;
\&        # Example: $from = A3, $to = B5
\&        my($sum) = SpreadSheet::Sum($spreadsheet, $from, $to);
\&        return (1, $sum);
\&    }
\&
\&    # Function returning another spreadsheet, thus a complex object
\&    sub double ($$$$$) {
\&        my($con, $data, $spreadsheet, $from, $to);
\&        # Doubles the region given by $from and $to, returns
\&        # a spreadsheet
\&        my($newSheet) = SpreadSheet::Double($spreadsheet, $from, $to);
\&        (1, $newSheet);
\&    }
\&
\&    # Quit function; showing the use of $data
\&    sub quit ($$) {
\&        my($con, $data) = @_;
\&        $$data = 0;   # Tell the server\*(Aqs Loop() method, that we
\&                      # are done.
\&        (1, "Bye!");
\&    }
\&
\&    # Now we give the handle functions a try. First of all, a
\&    # spreadsheet constructor:
\&    sub spreadsheet ($$$$) {
\&        my ($con, $data, $rows, $cols) = @_;
\&        my ($sheet, $handle);
\&        if (!defined($sheet = SpreadSheet::Empty($rows, $cols))) {
\&            $con\->error = "Cannot create spreadsheet";
\&            return (0, $con\->error);
\&        }
\&        if (!defined($handle = StoreHandle($con, $data, $sheet))) {
\&            return (0, $con\->error); # StoreHandle stored error message
\&        }
\&        (1, $handle);
\&    }
\&
\&    # Now a similar function to "double", except that a spreadsheet
\&    # is doubled, which is stored locally on the server and not
\&    # remotely on the client
\&    sub rdouble ($$$$$) {
\&        my($con, $data, $sHandle, $from, $to);
\&        my($spreadsheet) = UseHandle($con, $data, $sHandle);
\&        if (!defined($spreadsheet)) {
\&            return (0, $con\->error); # UseHandle stored an error message
\&        }
\&        # Doubles the region given by $from and $to, returns
\&        # a spreadsheet
\&        my($newSheet) = SpreadSheet::Double($spreadsheet, $from, $to);
\&        my($handle);
\&        if (!defined($handle = StoreHandle($con, $data, $newSheet))) {
\&            return (0, $con\->error); # StoreHandle stored error message
\&        }
\&        (1, $newSheet);
\&    }
\&
\&    # This function is called for any valid connection to a client
\&    # In a loop it processes the clients requests.
\&    #
\&    # Note, that we are using local data only, thus we should be
\&    # safe in a multithreaded environment. (Of course, no one knows
\&    # about the spreadsheet functions ... ;\-)
\&    sub Server ($) {
\&        my($con) = shift;
\&        my($con, $configFile, %funcTable);
\&        my($running) = 1;
\&        my(%handles) = (); # Note: handle hash is on the local stack
\&
\&        # First, create the servers function table. Note the
\&        # references to the handle hash in entries that access
\&        # the handle functions.
\&        %funcTable = {
\&            \*(Aqsum\*(Aq         => { \*(Aqcode\*(Aq => &sum },
\&            \*(Aqdouble\*(Aq      => { \*(Aqcode\*(Aq => &list },
\&            \*(Aqquit\*(Aq        => { \*(Aqcode\*(Aq => &quit,
\&                               \*(Aqdata\*(Aq = \e$running }
\&            \*(Aqspreadsheet\*(Aq => { \*(Aqcode\*(Aq => \e&spreadsheet,
\&                               \*(Aqhandles\*(Aq => \e%handles },
\&            \*(Aqrdouble\*(Aq     => { \*(Aqcode\*(Aq => \e&rdouble,
\&                               \*(Aqhandles\*(Aq = \e%handles },
\&
\&            # An alternative to the \*(Aqspreadsheet\*(Aq entry above;
\&            \*(AqNewHandle\*(Aq   => { \*(Aqcode\*(Aq => \e&RPC::pServer::NewHandle,
\&                               \*(Aqhandles\*(Aq => \e%handles,
\&                               \*(Aqclasses\*(Aq => [ \*(AqSpreadsheet\*(Aq ] },
\&
\&            # Give client access to *all* (!) spreadsheet methods
\&            \*(AqCallMethod\*(Aq  => { \*(Aqcode\*(Aq => \e&RPC::pServer::CallMethod,
\&                               \*(Aqhandles\*(Aq => \e%handles }
\&        };
\&
\&        $con\->{\*(AqfuncTable\*(Aq} = \e%funcTable;
\&
\&        while($running) {
\&            if (!$con\->Loop()) {
\&                $con\->Log(\*(Aqerr\*(Aq, "Exiting.\en"); # Error already logged
\&                exit 10;
\&            }
\&        }
\&        $con\->Log(\*(Aqnotice\*(Aq, "Client quits.\en");
\&        exit 0;
\&    }
\&
\&    # Avoid Zombie ball ...
\&    sub childGone { my $pid = wait; $SIG{CHLD} = \e&childGone; }
\&
\&    # Now for main
\&    {
\&        my ($iAmDaemon, $sock);
\&
\&        # Process command line arguments ...
\&        ...
\&
\&        # If running as daemon: Create a socket object.
\&        if ($iAmDaemon) {
\&            $sock = IO::Socket\->new(\*(AqProto\*(Aq => \*(Aqtcp\*(Aq,
\&                                    \*(AqListen\*(Aq => SOMAXCONN,
\&                                    \*(AqLocalPort\*(Aq => \*(AqwellKnownPort(42)\*(Aq,
\&                                    \*(AqLocalAddr\*(Aq => Socket::INADDR_ANY
\&                                   );
\&        } else {
\&            $sock = undef; # Let RPC::pServer create a sock object
\&        }
\&
\&        while (1) {
\&            # Wait for a client establishing a connection
\&            my $con = RPC::pServer(\*(Aqsock\*(Aq => $sock,
\&                                   \*(AqconfigFile\*(Aq => \*(Aqtestapp.conf\*(Aq);
\&            if (!ref($con)) {
\&                print STDERR "Cannot create server: $con\en";
\&            } else {
\&                if ($con\->{\*(Aqapplication\*(Aq} ne $MY_APPLICATION) {
\&                    # Whatever this client wants to connect to:
\&                    # It\*(Aqs not us :\-)
\&                    $con\->Deny("This is a $MY_APPLICATION server. Go away");
\&                } elsif ($con\->{\*(Aqversion\*(Aq} > $MY_VERSION) {
\&                    # We are running an old version of the protocol :\-(
\&                    $con\->Deny("Sorry, but this is version $MY_VERSION");
\&                } elsif (!IsAuthorizedUser($con\->{\*(Aquser\*(Aq},
\&                                           $con\->{\*(Aqpassword\*(Aq})) {
\&                    $con\->Deny("Access denied");
\&                } else {
\&                    # Ok, we accept the client. Spawn a child and let
\&                    # the child do anything else.
\&                    my $pid = fork();
\&                    if (!defined($pid)) {
\&                        $con\->Deny("Cannot fork: $!");
\&                    } elsif ($pid == 0) {
\&                        # I am the child
\&                        $con\->Accept("Welcome to the pleasure dome ...");
\&                        Server();
\&                    }
\&                }
\&            }
\&        }                       
\&    }
.Ve
.SH "SECURITY"
.IX Header "SECURITY"
It has to be said: pRPC 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 ...)
.PP
I highly recommend the following design principles:
.ie n .SS "Protection against ""trusted"" users"
.el .SS "Protection against ``trusted'' users"
.IX Subsection "Protection against trusted users"
.IP "perlsec" 4
.IX Item "perlsec"
Read the perl security \s-1FAQ\s0 (\f(CW\*(C`perldoc perlsec\*(C'\fR) and use the \f(CW\*(C`\-T\*(C'\fR switch.
.IP "taintperl" 4
.IX Item "taintperl"
\&\fBUse\fR the \f(CW\*(C`\-T\*(C'\fR switch. I mean it!
.IP "Verify data" 4
.IX Item "Verify data"
Never untaint strings withouth verification, better verify twice.
For example the \fICallMethod\fR function first checks, whether an
object handle is in a a proper format (currently integer numbers,
but don't rely on that, it could change). If it is, then it will
still be verified, that an object with the given handle exists.
.IP "Be restrictive" 4
.IX Item "Be restrictive"
Think twice, before you give a client access to a function. In
particular, think twice, before you give a client access to
objects via the handle methods: If a client can coerce
\&\fICallMethod()\fR on an object, he has access to *all* methods of
that object!
.IP "perlsec" 4
.IX Item "perlsec"
And just in case I forgot it: Read the \f(CW\*(C`perlsec\*(C'\fR man page. :\-)
.SS "Protection against untrusted users"
.IX Subsection "Protection against untrusted users"
.IP "Host based authorization" 4
.IX Item "Host based authorization"
pRPC has a builtin host based authorization scheme; use it!
See \*(L"\s-1CONFIGURATION FILE\*(R"\s0.
.IP "User based authorization" 4
.IX Item "User based authorization"
pRPC has no builtin user based authorization scheme; that doesn't
mean, that you should not implement one.
.IP "Encryption" 4
.IX Item "Encryption"
Using encryption with pRPC 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
DBD::pNET agent for an example.
.SH "AUTHOR"
.IX Header "AUTHOR"
Jochen Wiedmann, wiedmann@neckar\-alb.de
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fINet::pRPC::Client\fR\|(3), \fIStorable\fR\|(3), \fISys::Syslog\fR\|(3)
.PP
See \fIDBD::pNET\fR\|(3) for an example application.