[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