[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Question about writing custom backends for openldap
Michael Torrie wrote:
Browsing the source code for various backends for openldap, I see that
most of the backends define a type of global structure that they use to
store things like the database handle (for sql) etc. This is usually
stored in the private field of the BackendDB structure (if I recall
correctly). My question is a question of scope:
1. where is the correct place to store global information and
Since there can be multiple instances of a backend active at the same
time in a slapd configuration, there are very few valid uses for truly
global information. However, if it really is global, you can hang it off
the BackendInfo's bi_private pointer, or just declare it as global
variables in your backend code. I don't think the latter is a great idea.
2. what should be used to store information across just one connection
or session?
For example, when a bind event occurs that is deemed successful by
backend's handler, where can I store information about that bind that
will only persist across that connection. Subsequent calls to search,
for example, need to know that the user is properly authenticated. In
the perl and shell backends I can only see where a global information
structure is used.
Bind is a special case, as it is expected to return the authenticated
user's DN upon success. The slapd frontend stores this DN in the
connection structure. On a particular operation, the connection's DN is
also made available in the Operation structure. As such, any operation
only needs to look at the Operation DN to determine if the current
operation is authenticated or not.
Finally, is it up to the backend to enforce ACLs or does OpenLDAP
enforce the ACLS above backend somehow?
The frontend provides functions for checking ACLs; the backend must call
these functions at the appropriate points. The back-bdb code is probably
the best example. Most of the answers you're looking for are
self-evident in the back-bdb and back-ldbm code. The perl and shell
backends are not good models for new backend code; they omit quite a lot
of functionality that the embedded database backends exercise.
In general, you should think very carefully about the reasons that are
motivating you to write a custom backend. In many cases it's more
efficient to write an overlay that runs on top of an existing backend
instead. As a specific case in point, the password policy overlay
demonstrates how to maintain per-session information in the overlay's
private data.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support