openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

Re: R: ITS#6580
by masarati＠aero.polimi.it 25 Jun '10

25 Jun '10

> Hi, > the issue is that in release 2.4.21 is not possible execute an exended > operation registered in a plugin: THIS way doesnt work because slapd (in > extended.c fe_extended(), line 199) only look for built-in extended > operations and not plugin-defined extended operations (in a plugin calling > slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and SLAPI_EXT_OP_RET_VALUE). > > In fe_extended() I tried to extend the search to all extended operations > and now things start to work, but the main question concerns the choice of > backend. > > Uploaded files: > > servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch > servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch I think this approach is not correct, in many senses. First of all, you should use the native API instead of SLAPI. In fact, SLAPI is essentially unsupported. It was intended to give the possibility to somehow recycle software coded according to Netscape's API, but there's little point in developing new code based on that interface. Second, the whole purpose of implementing the slapi overlay was to avoid the pervasive presence of #ifdef LDAP_SLAPI in baseline code. So a more appropriate approach would be to have the slapi overlay register the extended operation using the native API, rather than having #ifdef LDAP_SLAPI in extended.c to check that any extop was loaded using SLAPI, as in gianluigi.nigro1-100625.patch. I can't say anything about gianluigi.nigro2-100625.patch because the file looks corrupted. p.

1 0

R: ITS#6580
by gianluigi.nigro＠passepartout.sm 25 Jun '10

25 Jun '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it]=20 Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p. -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato pu=F2 contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>R: ITS#6580</TITLE> </HEAD> <BODY>  Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> = gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >] Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be = successfully registered using OpenLDAP's native API, load_extop2().  See for = example overlays/dds.c p.    <hr color=3D'#D2D3D2' noshade> Il contenuto di questo messaggio di posta elettronica e = ogni eventuale documento a quest'ultimo allegato pu=F2 contenere = informazioni la cui riservatezza e' tutelata ed e' rivolto unicamente = agli effettivi destinatari i quali prendono atto del carattere non = strettamente personale dei messaggi di risposta, che potranno essere = noti all'organizzazione aziendale. Sono vietati la riproduzione e l'uso = di questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. </body></html> ------_=_NextPart_001_01CB14A1.5852206C--

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 25 Jun '10

25 Jun '10

Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Thanks, PE Le jeudi 24 juin 2010 à 19:27 +0200, masarati(a)aero.polimi.it a écrit : > The error is in the server: for this specific error, no response is > returned to the client. It is now fixed in HEAD, please test. Thanks, p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 24 Jun '10

24 Jun '10

The error is in the server: for this specific error, no response is returned to the client. It is now fixed in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

--On Wednesday, June 23, 2010 4:03 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > > Note: this comes in the form of: > > olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top > AUXILIARY MAY > ( dgIdentity $ dgAuthz ) ) > > > in dyngroup overlay (it lets you specify the internal identity to use for > the searches/auth identity). Never mind, browsing the dynlist code, I see this is implemented in there. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

--On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org wrote: Note: this comes in the form of: olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top AUXILIARY MAY ( dgIdentity $ dgAuthz ) ) in dyngroup overlay (it lets you specify the internal identity to use for the searches/auth identity). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

Full_Name: Quanah Gibson-Mount Version: 2.4.22 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When dynlist expands the group membership from a URI statement, it applies the bind identity to the search to expand it. This does not conform to the dyngroup behavior as was requested. Instead, dynlist should allow expansion by doing an internal search on the specified URI value, so that the binding identity is not required to have "compare" access on the attributes making up the query. This was implemented in dyngroup for security purposes, and those reasons still apply. --Quanah

1 0

(ITS#6583) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 23 Jun '10

23 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6582) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 22 Jun '10

22 Jun '10

1 0

(ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 22 Jun '10

22 Jun '10

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs