1.2. How Directory Server Plug-ins Work

You can configure Directory Server to load your plug-ins when Directory Server is started. After the plug-in has loaded, the Directory Server will resolve calls made to your plug-in functions as it processes the LDAP requests contained in your applications.
Internally, the Directory Server has hooks that allow you to register your own functions to be called when specific events occur. For example, the Directory Server has hooks to call a registered plug-in in the following situations:
  • Before preforming an LDAP operation (for example, before an entry is added to the directory).
  • When adding, modifying, removing, renaming, or searching for entries in the database.
  • After performing an LDAP operation (for example, after an entry is added to the directory).
  • Before writing an entry to the database.
  • After reading an entry from the database.
  • When processing an extended operation.
  • When indexing an attribute.
  • When filtering search result candidates based on an attribute.
When you register your plug-in functions, you specify the function type and the plug-in type. Together, these specifications indicate when the function is called. Refer to Section 1.3, “Types of Directory Server Plug-ins”.

1.2.1. Calling Directory Server Plug-in Functions

At specific LDAP events, the Directory Server calls all plug-in functions that are registered for that event. For example, before performing an LDAP add operation (an add event), the server calls all plug-in functions registered as pre-operation add functions. When the add operation is completed, the server will call all registered post-operation add functions.
In most plug-in function calls, the server passes a parameter block structure (also called a pblock or Slapi_PBlock) to the function. The parameter block contains data relevant to the operation. In most Directory Server plug-in functions you write, you access and modify the data in the parameter block.
For example, when the Directory Server receives an LDAP add request, the server does the following:
  1. Parses the request, and retrieves the new DN and the entry to be added.
  2. Places pointers to the DN and the entry in the parameter block.
  3. Calls any registered pre-operation add functions, passing the parameter block to these functions.
  4. Calls the registered database add function (which is responsible for adding the entry to the directory database), and passes to it the parameter block.
  5. Calls any registered post-operation add functions, passing the parameter block to these functions.
If you are writing a function that is invoked before an LDAP operation is performed, you can prevent the operation from being performed. For example, you can write a function that validates data before a new entry is added to the directory. If the data is not valid, you can prevent the LDAP add operation from occurring and return an error message to the LDAP client.
In some situations, you can also set the data that is used by the server to perform an operation. For example, in a pre-operation add function, you can change an entry before it is added to the directory.

1.2.2. The Directory Server Architecture

Internally, the Directory Server consists of two major subsections, the front-end and the backend.
The front-end receives LDAP requests from clients and processes those requests. When processing requests, the front-end calls functions in the backend to read and write data. The front-end then sends the results back to the client.
The backend reads and writes data to the database containing the directory entries. The backend abstracts the database from the front-end. The data stored in a backend is identified by the suffixes that the backend supports. For example, a backend that supports the dc=example,dc=com suffix contains directory entries that end with that suffix.
The following diagram illustrates the Directory Server architecture.
Directory Server Architecture

Figure 1.1. Directory Server Architecture