fix operational attrs return with chain overlay (ITS#4431); misc cleanup

This commit is contained in:
Pierangelo Masarati 2006-03-24 22:49:51 +00:00
parent 6cfb262564
commit 00073c8cac
4 changed files with 24 additions and 36 deletions

View File

@ -219,25 +219,6 @@ ldap_chain_uri_dup( void *c1, void *c2 )
return 0;
}
static int
ldap_chain_operational( Operation *op, SlapReply *rs )
{
/* Trap entries generated by back-ldap.
*
* FIXME: we need a better way to recognize them; a cleaner
* solution would be to be able to intercept the response
* of be_operational(), so that we can divert only those
* calls that fail because operational attributes were
* requested for entries that do not belong to the underlying
* database. This fix is likely to intercept also entries
* generated by back-perl and so. */
if ( rs->sr_entry->e_private == NULL ) {
return 0;
}
return SLAP_CB_CONTINUE;
}
/*
* Search specific response that strips entryDN from entries
*/
@ -270,6 +251,10 @@ ldap_chain_cb_search_response( Operation *op, SlapReply *rs )
}
}
/* tell the frontend not to add generated
* operational attributes */
rs->sr_flags |= REP_NO_OPERATIONALS;
return SLAP_CB_CONTINUE;
} else if ( rs->sr_type == REP_SEARCHREF ) {
@ -786,7 +771,11 @@ cleanup:;
case LDAP_SUCCESS:
case LDAP_REFERRAL:
/* slapd-ldap sent response */
assert( sc2.sc_private == LDAP_CH_RES );
if ( !op->o_abandon ) {
/* FIXME: should we send response? */
Debug( LDAP_DEBUG_ANY, "%s: ldap_chain_response: overlay should have sent result.\n",
op->o_log_prefix, 0, 0 );
}
break;
default:
@ -1807,17 +1796,6 @@ chain_initialize( void )
ldapchain.on_bi.bi_db_close = ldap_chain_db_close;
ldapchain.on_bi.bi_db_destroy = ldap_chain_db_destroy;
/* ... otherwise the underlying backend's function would be called,
* likely passing an invalid entry; on the contrary, the requested
* operational attributes should have been returned while chasing
* the referrals. This all in all is a bit messy, because part
* of the operational attributes are generated by the backend;
* part by the frontend; back-ldap should receive all the available
* ones from the remote server, but then, on its own, it strips those
* it assumes will be (re)generated by the frontend (e.g.
* subschemaSubentry.) */
ldapchain.on_bi.bi_operational = ldap_chain_operational;
ldapchain.on_bi.bi_connection_destroy = ldap_chain_connection_destroy;
ldapchain.on_response = ldap_chain_response;

View File

@ -314,6 +314,10 @@ ldap_back_cf_gen( ConfigArgs *c )
struct berval bv = BER_BVNULL;
rc = 0;
if ( li == NULL ) {
return 1;
}
switch( c->type ) {
case LDAP_BACK_CFG_URI:
if ( li->li_uri != NULL ) {

View File

@ -1709,15 +1709,17 @@ fe_aux_operational(
* and the backend supports specific operational attributes,
* add them to the attribute list
*/
if ( SLAP_OPATTRS( rs->sr_attr_flags ) || ( rs->sr_attrs &&
ad_inlist( slap_schema.si_ad_entryDN, rs->sr_attrs ) ) )
if ( !( rs->sr_flags & REP_NO_ENTRYDN )
&& ( SLAP_OPATTRS( rs->sr_attr_flags ) || ( rs->sr_attrs &&
ad_inlist( slap_schema.si_ad_entryDN, rs->sr_attrs ) ) ) )
{
*ap = slap_operational_entryDN( rs->sr_entry );
ap = &(*ap)->a_next;
}
if ( SLAP_OPATTRS( rs->sr_attr_flags ) || ( rs->sr_attrs &&
ad_inlist( slap_schema.si_ad_subschemaSubentry, rs->sr_attrs ) ) )
if ( !( rs->sr_flags & REP_NO_SUBSCHEMA)
&& ( SLAP_OPATTRS( rs->sr_attr_flags ) || ( rs->sr_attrs &&
ad_inlist( slap_schema.si_ad_subschemaSubentry, rs->sr_attrs ) ) ) )
{
*ap = slap_operational_subschemaSubentry( op->o_bd );
ap = &(*ap)->a_next;

View File

@ -1972,6 +1972,10 @@ typedef struct slap_rep {
#define REP_ENTRY_MUSTRELEASE 0x0004U
#define REP_MATCHED_MUSTBEFREED 0x0010U
#define REP_REF_MUSTBEFREED 0x0020U
#define REP_NO_ENTRYDN 0x1000U
#define REP_NO_SUBSCHEMA 0x2000U
#define REP_NO_OPERATIONALS (REP_NO_ENTRYDN|REP_NO_SUBSCHEMA)
} SlapReply;
/* short hands for response members */