Rich,
Thanks. I actually did have the address of operator on the code. Both the init and config are defining only a couple of specific functions (start_fn, pre_results_fn,pre_abandon_fn) one function defined for each.
The one I am testing is preop_results() which does trigger, works as you suggested below, but crashes when adding a call to slapi_entry_attr_find() for many but not all remote inquiries.
Perhaps I am going at this all wrong. What sequence should I call to get a multivariable attribute? In this case a list of attribute ‘memberUid’ while rejecting preop_results not directed at returning Group information?
JD
From: 389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Rich Megginson
Sent: Thursday, January 16, 2014 2:25 PM
To: 389 Directory server developer discussion.
Subject: Re: [389-devel] plugin problem using slapi_entry_attr_find
Another bug in your code. The argument for SLAPI_SEARCH_ATTRS should be the address of a char **.e.g.
{
char **attrs;
int ii = 0;
...
if (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &attrs) !=0 )return (-1);
for (ii = 0; attrs && attrs[ii]; ++ii) {
slapi_log_error(SLAPI_LOG_PLUGIN, "my plugin",
"search attr %d is %s\n", ii, attrs[ii]);
}
...
In your plugin entry and in your plugin config you specify which types of operations (bind, search, add, etc.) your plugin will handle.
E.g. a SLAPI_PLUGIN_PRE_BIND_FN will be called at the pre-operation stage of a BIND operation.
Each type of plugin will have possibly different pblock parameters available. So, for example, if you use the same function as both a bind preop and a search preop - when called as a bind preop, the SLAPI_SEARCH_ATTRS will not be available.
If you want to use the same function for different op types, declare different functions for each op type, then call your common function with the op type, like this:
int
bind_preop(Slapi_PBlock *pb) {
return common_function(SLAPI_PLUGIN_PRE_BIND_FN, pb);
}
int
search_preop(Slapi_PBlock *pb) {
return common_function(SLAPI_PLUGIN_PRE_SEARCH_FN, pb);
}
...
int
common_function(int type, Slapi_PBlock *pb) {
...
if (type == SLAPI_PLUGIN_PRE_BIND_FN) {
do some bind specific action
} else if (type == SLAPI_PLUGIN_PRE_SEARCH_FN) {
do some search specific action
}
...
On 01/16/2014 03:02 PM, Deas, Jim wrote:
On further review it appears that the line in question will crash Dirsrv on some request from PAM or even 389-Console but not when searching groups via ldapsearch
Should there be a statement that determines what type of query triggered the preop_result so I know if it’s proper to look for attributes?
On 01/16/2014 11:39 AM, Deas, Jim wrote:
My bet, a rookie mistake. Am I forgetting to init a pointer etc???
Adding the line surrounded by ****** in this routine makes dirsrv unstable and crashes it after a few queries.
/* Registered preop_result routine */
int gnest_preop_results( Slapi_PBlock *pb){
Slapi_Entry *e;
Slapi_Attr **a;
This should be Slapi_Attr *a;
If (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &e) !=0 )return (-1);
/*****************This line makes the server unstable and crashes it after one or two queries ********************/
If(slapi_entry_attr_find(e, “memberUid”,&a) == 0) slapi_log_error(SLAPI_LOG_PLUGIN, “gnest preop”,”memberUid found in record);
/******************************************************************************************************/
Return (0);
}
JD
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
