The Netscape Directory Server (Directory Server) provides some general-purpose, front-end API functions that allow you to work with the entries in the Directory Server. This chapter explains how to use the front-end API functions to accomplish various tasks; you can call these functions in your plug-in to interact with the client (for example, send results or result codes), log messages, and work with entries, attributes, and filters. While all of the functions described here must be used in conjunction with other API functions, understanding how these functions work will help you understand how to program other plug-in API functions.
This chapter contains the following sections:
The front-end functions are declared in the
slapi-plugin.h header file.
To write an error message to the error log, call the slapi_new_condvar() function. For example, the following slapi_log_error() function call writes a message in the error log:
slapi_log_error(
SLAPI_LOG_PLUGIN, "searchdn_preop_search",
"***
PREOPERATION SEARCH PLUGIN ***\n");
This call will create the following message in the error log:
[01/Oct/1997:02:24:18
-0700] searchdn_preop_search \
- ***
PREOPERATION SEARCH PLUGIN ***
Make sure that the Directory Server is
configured to log messages that have the severity that you specify (for
example,
SLAPI_LOG_PLUGIN). For more information, see Setting the Log Level of the
Server.
When the backend database processes a search operation, it attempts to use indexes to narrow down the list of candidates matching the search criteria. If the backend is unable to use indexes, it appends the following string to the access log entry for the search:
This note indicates that an unindexed search was performed.
If you are writing your own backend database search function, you can append this note to access log entries by setting the SLAPI_OPERATION_NOTES parameter to the flag SLAPI_OP_NOTE_UNINDEXED. This parameter identifies any notes that need to be appended to access log entries. Currently, SLAPI_OP_NOTE_UNINDEXED is the only value that you can set for this parameter. In future releases, additional flags will be defined. You will be able to use bitwise OR combinations of flags to specify different combinations of notes.
The server appends these notes and writes out the access log entries whenever sending a result or search entry back to the client.
Sometimes you might need to communicate various information directly back to the client. For example, you might want to do this in the following situations:
For example, the following statement sends an LDAP_SUCCESS status code back to the client.
slapi_send_ldap_result(pb,
LDAP_SUCCESS, NULL, \
"The
operation was processed successfully.\n", 0, NULL);
|
|
|
|
It is important that you send only one result per operation back to the client. |
|
|
|
|
At any point in time, the client can choose to abandon an LDAP operation. When writing database functions, keep in mind that you should periodically check to see if the operation has been abandoned.
To determine if an operation has been abandoned, call slapi_op_abandoned(). For example:
if (
slapi_op_abandoned( pb ) ) {
slapi_log_error( SLAPI_LOG_PLUGIN, "my_function",
"The
operation was abandoned.\n" );
return 1;
}
This section discusses how to create new entries in the directory and how to convert them to LDIF and back.
In certain situations, you will need to pass directory entries between the front-end and the client. For example, it you create a custom add function, the front-end passes to your function an entry in the parameter block. When you perform a search operation, you return each matching search entry to the client.
When working with entries, you use the Slapi_Entry datatype to get attribute value pairs. The front-end routines listed in Front-End Functions for Manipulating Entries and Attributes are designed to help you manipulate entries passed in parameter blocks. These functions are described in more detail in the sections that follow the table.
|
Convert an entry to an LDIF string representation and vice versa. |
|
In some situations, you might need to create a new entry. There are two basic ways to do this:
When you are finished using the entry, you
should free it from memory by calling the slapi_entry_free()
function.
Entries can be stored in LDIF files. When stored in these files, entries are converted into a string representation. The following format is the LDIF string representation for a directory entry:
dn:[:]
<dn>\n
[<attr>:[:]
<value>\n]
[<attr>:[:]
<value>\n]
[<space><continuedvalue>\n]*
...
If you want to continue the specification of a value on additional lines (in other words, if the value wraps around to another line), use a single space (the ASCII 32 character) at the beginning of subsequent lines. For example:
dn: cn=Jane Doe
inski,
ou=Accoun
ting, o=ex
ample.com
Refer to the Netscape Directory Server Administrator's Guide for details on DN syntax.
If a double-colon is used after a data type, it signifies that the value after the double-colon is encoded as a base-64 string. Data is sometimes encoded as a base-64 string. For example, it might be encoded this way if the value contains a non-printing character or newline.
To get the LDIF string representation of an entry (and vice versa), call the following functions:
When you are done working with the entry,
you should call the slapi_entry_free()
function.
You can call the following two front-end routines to get and set the DN for an entry:
Before you add or modify an entry in the database, you may want to verify that the new or changed entry still complies with the database schema.
To see if an entry complies with the schema, call the slapi_entry_schema_check() function.
There are two basic ways to obtain the attributes and values of an entry:
Once you find the attribute you are looking
for, use slapi_attr_value_find()
to return the value of that attribute.
To iterate through the attributes associated with an entry, call the slapi_entry_first_attr() function to get the first attribute of the entry. This function returns a pointer to the first attribute in the entry. With a pointer to the attribute, you can test to see if it is the attribute in which you are interested.
To retrieve the subsequent attributes in the entry, call slapi_entry_next_attr(), passing to it the pointer to the current attribute in the cookie parameter of the function. Like slapi_entry_first_attr(), slapi_entry_next_attr() returns a pointer to the current attribute.
Once you find the attribute you need, you
can retrieve its value using slapi_attr_value_find().
To see if an entry
contains a specific attribute, call slapi_entry_attr_find().
This function returns 0 if the
entry contains the attribute, -1 if it
does not.
You can also call front-end routines to add or remove attributes and values in an entry. The front-end provides the following functionality:
In certain situations, the front-end passes DNs to the backend through the parameter block. For example, when calling the add function, the parameter block includes a parameter that specifies the DN of the new entry to be added.
If you need to manipulate DNs within parameter blocks, you can call the following front-end routines:
|
Determines if a DN is the root DN (the DN of the privileged superuser). |
|
|
Determines if a DN is a suffix served by one of the server's back-ends. |
|
To determine if a DN is the root DN, call slapi_dn_isroot(). This function returns 1 if the specified DN is the root DN of the local database. It returns 0 if the DN is not the root DN.
A suffix of a DN identifies a subtree in the directory tree where the DN is located. For example, consider the following DN:
cn=Babs Jensen,ou=Product Development,o=Example Corporation,c=US
In this case, one of the suffixes is:
This suffix indicates that the Babs Jensen entry is located in the Example Corporation subtree in the directory tree.
To determine if a value is a suffix for a
DN, call slapi_dn_issuffix().
To determine if a DN is one of the suffixes served by the backend, call
the slapi_dn_isbesuffix()
function.
The suffix directive in the server configuration file specifies which DNs are served by a particular backend. For example, suppose the suffix directive is configured to the following:
suffix "o=Example Corporation,c=US"
Here, all entries within the o=Example Corporation,c=US subtree are served by this backend.
To get a copy of the parent DN for a DN, call the slapi_dn_parent() function or the slapi_dn_beparent() function.
These functions return the parent DN of dn. If dn is a suffix served by the backend, slapi_dn_beparent() will return NULL.
When you are done working with the parent DN, you should free it from memory by calling free().
If you need to compare DNs (for example, if you are searching your database for a particular DN), you should normalize the DNs that you are comparing to ensure that they are properly compared.
You can use the following front-end function to normalize and convert the case of a DN:
|
|
|
|
These functions operate on the actual DN specified in the argument, not a copy of the DN. If you want to modify a copy of the DN, call slapi_ch_strdup() to make a copy of the DN. |
|
|
|
|
When a client requests an LDAP search operation, the front-end passes the search filter to the backend as part of the parameter block. (The filter is passed through the SLAPI_SEARCH_FILTER parameter. A string representation of the filter is also available in the SLAPI_SEARCH_STRFILTER parameter.)
To manipulate search filters, call the following front-end routines:
After retrieving a filter from the SLAPI_SEARCH_FILTER parameter of the parameter block, you can call the slapi_filter_test() function to determine if entries in your database match the filter.
To determine the type of filter you are using, call slapi_filter_get_choice(). This function returns the filter type, which can be any one of the following values:
To get the search criteria specified by a search filter, call one of the following functions:
Both of these functions will return either a filter component of the complex filter or a NULL value, according to the following:
|
|
|
|
You do not need to free the values returned by the slapi_filter_get_ava(), slapi_filter_get_type(), and slapi_filter_get_subfilt() functions. |
|
|
|
|
A search filter can be represented by either the datatype Slapi_Filter or as a string. In a parameter block for a search operation, SLAPI_SEARCH_FILTER is a filter of the datatype Slapi_Filter and SLAPI_SEARCH_STRFILTER is the string representation of that filter. In general, it is easier to specify a filter as a string than it is to construct a filter from the type Slapi_Filter.
To convert the string representation of a filter into a filter of the datatype Slapi_Filter, call the slapi_str2filter() function.
When you are done working with the filter, you should free it by calling the slapi_filter_free() function.
You can use AND, OR and NOT to combine different filters to create a complex filter. To do this, call the slapi_filter_join() function.
The slapi_filter_join() function returns the complex filter you've created. When you are done using the complex filter, you should free it by calling slapi_filter_free().
Filters of the type LDAP_FILTER_NOT can have only one component. If the filter type (ftype) is LDAP_FILTER_NOT, you must pass a NULL value for the second filter when calling slapi_filter_join().
When Directory Server 4.x stores the password for an entry in the userpassword attribute, it encodes the password using the scheme specified in the passwdhash directive of the configuration file. The scheme can be crypt, sha, or "." (for cleartext).
By default, current versions of Directory Server use the userpassword attribute to store the credentials for an entry. The server encodes the password using the scheme specified in the nsslapd-rootpwstoragescheme or passwordStorageScheme attributes of the cn=config entry contained in the dse.ldif file. The scheme can be any of the following:
To determine if a given password is one of
the values of the userpassword
attribute, call slapi_pw_find_sv().
This function determines which password scheme was used to store the
password and uses the appropriate comparison function to compare a
given value against the encrypted values of the userpassword
attribute.
| Previous |
Contents |
Index |
DocHome | Next |