REQUIRED OPTIONS

There is no authentication or encryption active in this minimal configuration, so aware that this may be a big security risk! Adding security is easy, refer to the chapters about SSL and authentication.

These are the required options:

port

TCP port number of the RPC listener.

classes

This is a hash ref with the following structure:

  classes => {
    "Class1" => {
      new             => "_constructor",
      simple_method   => 1,
      object_returner => "_object",
    },
    "Class2" => { ... },
    ...
  },
    

Each class which should be accessable for clients needs to be listed here at the first level, assigned a hash of methods allowed to be called. Event::RPC disuinguishes three types of methods by classifying their return value:

SSL OPTIONS

First you need to generate a server key and certificate for your server using the openssl command which is part of the OpenSSL distribution, e.g. by issueing these commands (please refer to the manpage of openssl for details - this is a very rough example, which works in general, but probably you want to tweak some parameters):

  % openssl genrsa -des3 -out server.key 1024
  % openssl req -new -key server.key -out server.csr
  % openssl x509 -req -days 3600 -in server.csr \
            -signkey server.key -out server.crt

After executing these commands you have the following files

  server.crt
  server.key
  server.csr

Event::RPC needs the first two of them to operate with SSL encryption.

To enable SSL encryption you need to pass the following options to the constructor:

ssl

The ssl option needs to be set to 1.

ssl_key_file

This is the filename of the server.key you generated with the openssl command.

ssl_cert_file

This is the filename of the server.crt file you generated with the openssl command.

ssl_passwd_cb

Your server key is encrypted with a password you entered during the key creation process described above. This callback must return it. Depending on how critical your application is you probably must request the password from the user during server startup or place it into a more or less secured file. For testing purposes you can specify a simple anonymous sub here, which just returns the password, e.g.

  ssl_passwd_cb => sub { return "topsecret" }
    

But note: having the password in plaintext in your program code is insecure!

AUTHENTICATION OPTIONS

Since version 0.87 Event::RPC has an API to delegate authentication tasks to a module, which can be implemented outside Event::RPC. To be compatible with prior releases it ships the module Event::RPC::AuthPasswdHash which implements the old behaviour transparently.

This default implementation is a simple user/password based model. For now this controls just the right to connect to your server, so knowing one valid user/password pair is enough to access all exported methods of your server. Probably a more differentiated model will be added later which allows granting access to a subset of exported methods only for each user who is allowed to connect.

The following options control the authentication:

auth_required

Set this to 1 to enable authentication and nobody can connect your server until he passes a valid user/password pair.

auth_passwd_href

If you like to use the builtin Event::RPC::AuthPasswdHash module simply set this attribute. If you decide to use auth_module (explained beyound) it's not necessary.

auth_passwd_href is a hash of valid user/password pairs. The password stored here needs to be encrypted using Perl's crypt() function, using the username as the salt.

Event::RPC has a convenience function for generating such a crypted password, although it's currently just a 1:1 wrapper around Perl's builtin crypt() function, but probably this changes someday, so better use this method:

  $crypted_pass = Event::RPC->crypt($user, $pass);
    

This is a simple example of setting up a proper auth_passwd_href with two users:

  auth_passwd_href => {
    fred => Event::RPC->crypt("fred", $freds_password),
    nick => Event::RPC->crypt("nick", $nicks_password),
  },
    

auth_module

If you like to implement a more complex authentication method yourself you may set the auth_module attribute to an instance of your class. For now your implementation just needs to have this method:

  $auth_module->check_credentials($user, $pass)
    

Aware that $pass is encrypted as explained above, so your original password needs to by crypted using Event::RPC->crypt as well, at least for the comparison itself.

Note: you can use the authentication module without SSL but aware that an attacker listening to the network connection will be able to grab the encrypted password token and authenticate himself with it to the server (replay attack). Probably a more sophisticated challenge/response mechanism will be added to Event::RPC to prevent this. But you definitely should use SSL encryption in a critical environment anyway, which renders grabbing the password from the net impossible.

LOGGING OPTIONS

logger

To enable logging just pass such an Event::RPC::Logger object to the constructor.

start_log_listener

Additionally Event::RPC can start a log listener on the server's port number incremented by 1. All clients connected to this port (e.g. by using telnet) get the server's log output.

Note: currently the logging port supports neither SSL nor authentication, so be careful enabling the log listener in critical environments.

MAINLOOP OPTIONS

loop

This option takes an object of the loop abstraction layer you want to use. Currently the following modules are implemented:

  Event::RPC::Loop::AnyEvent  Use the AnyEvent module
  Event::RPC::Loop::Event     Use the Event module
  Event::RPC::Loop::Glib      Use the Glib module
    

If loop isn't set, Event::RPC::Server tries all supported modules in a row and aborts the program, if no module was found.

More modules will be added in the future. If you want to implement one just take a look at the code in the modules above: it's really easy and I appreciate your patch. The interface is roughly described in the documentation of Event::RPC::Loop.

If you use the Event::RPC->start() method as described in the SYNOPSIS Event::RPC will enter the correspondent main loop for you. If you want to have full control over the main loop, use this method to setup all necessary Event::RPC listeners:

  $rpc_server->setup_listeners();

and manage the main loop stuff on your own.

MISCELLANEOUS OPTIONS

host

By default the network listeners are bound to all interfaces in the system. Use the host option to bind to a specific interface, e.g. "localhost" if you efficently want to prevent network clients from accessing your server.

load_modules

Control whether the class module files should be loaded automatically when first accesed by a client. This options defaults to true, for backward compatibility reasons.

auto_reload_modules

If this option is set Event::RPC::Server will check on each method call if the corresponding module changed on disk and reloads it automatically. Of course this has an effect on performance, but it's very useful during development. You probably shouldn't enable this in production environments.

connection_hook

This callback is called on each connection / disconnection with two arguments: the Event::RPC::Connection object and a string containing either "connect" or "disconnect" depending what's currently happening with this connection.