Net::LDAP::Server(3) LDAP server side protocol handling

SUBCLASSING

You can subclass Net::LDAP::Server with the following lines:

  package MyServer;
  use Net::LDAP::Server;
  use base 'Net::LDAP::Server';

Then you can add your custom methods by just implementing a subroutine named after the name of each method. These are supported methods:

"bind"
"unbind"
"search"
"add"
"modify"
"delete"
"modifyDN"
"compare"
"abandon"

For any method that is not supplied, Net::LDAP::Server will return an "LDAP_UNWILLING_TO_PERFORM".

new()

You can also subclass the "new" constructor to do something at connection time:

  sub new {
     my ($class, $sock) = @_;
     my $self = $class->SUPER::new($sock);
     printf "Accepted connection from: %s\n", $sock->peerhost();
     return $self;
  }

Note that $self is constructed using the fields pragma, so if you want to add data to it you should add a line like this in your subclass:

  use fields qw(myCustomField1 myCustomField2);

Methods

When a method is invoked it will be obviously passed $self as generated by "new", and two variables:

* the Request datastructure that is specific for this method (e.g. BindRequest);
* the full request message (useful if you want to access messageID or controls parts)

You can look at Net::LDAP::ASN or use Data::Dumper to find out what is presented to your method:

  use Data::Dumper;
  sub search {
     print Dumper \@_;
  }

If anything goes wrong in the module you specify (e.g. it died or the result is not a correct ldapresult structure) Net::LDAP::Server will return an "LDAP_OPERATIONS_ERROR" where the errorMessage will specify what went wrong.

All methods should return a LDAPresult hashref, for example:

  return({
      'matchedDN' => '',
      'errorMessage' => '',
      'resultCode' => LDAP_SUCCESS
  });

"search" should return a LDAPresult hashref followed by a list of entries (if applicable). Entries may be coded either as searchResEntry or searchRefEntry structures or as Net::LDAP::Entry or Net::LDAP::Reference objects.