I programmed something like this very simple code inside an overlay. The idea is quite simple: if a search fulfills a condition, a new search should be done and the retrieved entries should also be returned to the client. (It is ensured that the second search does not fulfill the condition).
static int response( Operation *op, SlapReply *rs ){
if ( op->o_tag == LDAP_REQ_SEARCH ){
switch ( rs->sr_type ){
case REP_SEARCH: // Show op and rs values in the debug console Debug(LDAP_DEBUG_TRACE, "#################### I Enter REP_SEARCH +++++++++++++++++\n",0,0,0); return SLAP_CB_CONTINUE; break;
case REP_RESULT: // Show op and rs values in the debug console Debug(LDAP_DEBUG_TRACE, "#################### I Enter REP_RESULT +++++++++++++++++\n",0,0,0); // Check for subsearch condition ... if (check){ // Op2 initialize Operation op2 = *op; // Some op2 initialization code (just change the filter so the result of the previous check is false next time for this over config) Debug(LDAP_DEBUG_TRACE, "#################### Subsearch: start *****\n",0,0,0);
[Option1: op2.o_bd = select_backend( &op->o_req_ndn, get_manageDSAit( op ), 1 ); (op2.o_bd->be_search)( &op2, rs ); ] [ Option2: fe_op_search( &op2, &rr ); ]
Debug(LDAP_DEBUG_TRACE, "#################### Subsearch: finish ************\n",0,0,0); } return SLAP_CB_CONTINUE; break; } } return SLAP_CB_CONTINUE; }
The code is just that simple but I found that when the subsearch is done, the ldap server runs the response twice for each retrieved entry. I suppose that the entries are being sent twice regardless of the search function I use (fe_op_search or be_search).
Anyone can give me a hint on why? Are those the correct searching functions? If so, which one is more appropriate?
José Marco wrote:
I programmed something like this very simple code inside an overlay. The idea is quite simple: if a search fulfills a condition, a new search should be done and the retrieved entries should also be returned to the client. (It is ensured that the second search does not fulfill the condition).
static int response( Operation *op, SlapReply *rs ){
if ( op->o_tag == LDAP_REQ_SEARCH ){ switch ( rs->sr_type ){ case REP_SEARCH: // Show op and rs values in the debug console Debug(LDAP_DEBUG_TRACE, "#################### I Enter
REP_SEARCH +++++++++++++++++\n",0,0,0); return SLAP_CB_CONTINUE; break;
case REP_RESULT: // Show op and rs values in the debug console Debug(LDAP_DEBUG_TRACE, "#################### I Enter
REP_RESULT +++++++++++++++++\n",0,0,0); // Check for subsearch condition ... if (check){ // Op2 initialize Operation op2 = *op; // Some op2 initialization code (just change the filter so the result of the previous check is false next time for this over config) Debug(LDAP_DEBUG_TRACE, "#################### Subsearch: start *****\n",0,0,0);
[Option1: op2.o_bd = select_backend( &op->o_req_ndn,
get_manageDSAit( op ), 1 ); (op2.o_bd->be_search)( &op2, rs ); ] [ Option2: fe_op_search( &op2, &rr ); ]
Debug(LDAP_DEBUG_TRACE, "####################
Subsearch: finish ************\n",0,0,0); } return SLAP_CB_CONTINUE; break; } } return SLAP_CB_CONTINUE; }
The code is just that simple but I found that when the subsearch is
done, the ldap server runs the response twice for each retrieved entry. I suppose that the entries are being sent twice regardless of the search function I use (fe_op_search or be_search).
Anyone can give me a hint on why?
Your response() callback is still in place when you do your subsearch, and invoking the subsearch invokes your overlay again, therefore the callback exists twice in the callback stack so it runs twice. You need to check earlier for this case and return if you're already inside your subsearch.
Nice! I'm almost done with my nested groups overlay. I'm wishing to contribute it! (Some previous cleaning and translation needed before, though ;) )
It's not trivial to take a general picture of OpenLDAP's inside! Thanks a lot for the infos, Pierangelo and Howard!
Howard Chu escribió:
José Marco wrote:
I programmed something like this very simple code inside an overlay. The idea is quite simple: if a search fulfills a condition, a new search should be done and the retrieved entries should also be returned to the client. (It is ensured that the second search does not fulfill the condition).
static int response( Operation *op, SlapReply *rs ){
if ( op->o_tag == LDAP_REQ_SEARCH ){ switch ( rs->sr_type ){ case REP_SEARCH: // Show op and rs values in the debug console Debug(LDAP_DEBUG_TRACE, "#################### I Enter
REP_SEARCH +++++++++++++++++\n",0,0,0); return SLAP_CB_CONTINUE; break; case REP_RESULT: // Show op and rs values in the debug console Debug(LDAP_DEBUG_TRACE, "#################### I Enter REP_RESULT +++++++++++++++++\n",0,0,0); // Check for subsearch condition ... if (check){ // Op2 initialize Operation op2 = *op; // Some op2 initialization code (just change the filter so the result of the previous check is false next time for this over config) Debug(LDAP_DEBUG_TRACE, "#################### Subsearch: start *****\n",0,0,0);
[Option1: op2.o_bd = select_backend( &op->o_req_ndn,
get_manageDSAit( op ), 1 ); (op2.o_bd->be_search)( &op2, rs ); ] [ Option2: fe_op_search( &op2, &rr ); ]
Debug(LDAP_DEBUG_TRACE, "####################
Subsearch: finish ************\n",0,0,0); } return SLAP_CB_CONTINUE; break; } } return SLAP_CB_CONTINUE; }
The code is just that simple but I found that when the subsearch
is done, the ldap server runs the response twice for each retrieved entry. I suppose that the entries are being sent twice regardless of the search function I use (fe_op_search or be_search).
Anyone can give me a hint on why?
Your response() callback is still in place when you do your subsearch, and invoking the subsearch invokes your overlay again, therefore the callback exists twice in the callback stack so it runs twice. You need to check earlier for this case and return if you're already inside your subsearch.
José Marco schrieb:
Nice! I'm almost done with my nested groups overlay. I'm wishing to contribute it! (Some previous cleaning and translation needed before, though ;) )
Hi José Marco,
Did you suceed with your nested groups overlay? I'd be interested if I could use/adapt it for my replicated apple crap ;)
cheers Paul
openldap-software@openldap.org