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?
*From:*389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx>
[mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] *On Behalf Of
*Rich Megginson
*Sent:* Thursday, January 16, 2014 11:29 AM
*To:* 389 Directory server developer discussion.
*Subject:* Re: [389-devel] plugin problem using
slapi_entry_attr_find
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
<mailto:389-devel@xxxxxxxxxxxxxxxxxxxxxxx>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
<mailto: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
