|
From: <mi...@st...> - 2002-08-31 18:48:44
|
HI! See final analysis below. Just for the records. Remind when doing error handling with wrapped OpenLDAP functions in future. Ciao, Michael. -------- Original Message -------- Subject: Re: Liberal parsing of schema elements (ITS#1996) Date: Thu, 29 Aug 2002 11:00:56 GMT From: Howard Chu <ope...@Op...> To: mi...@st... > Kurt D. Zeilenga wrote: >> I misunderstood the nature of the problem. The >> client library ALLOW flags, if properly enabled, >> should be able to parse these non-conformant >> values. If they aren't working, that's a bug. >> Patches welcomed. The code parses the string just fine and returns a valid LDAPObjectClass result. It just happens to leave a non-zero error code set as well, left over from its attempt to find a numeric OID. With the ALLOW flags set, that code is ignored and the parse continues. Since the return value is non-NULL Python should not be treating this as a failure. > > Any progress on this? > > Unfortunately I'm not a C programmer. I looked at the OpenLDAP > code and AFAICS there is code to allow non-numeric OIDs if the > proper ALLOW flag is set. > > The author of the relevant parts in python-ldap double-checked > that the ALLOW flags are properly passed to OpenLDAP's schema > parsing functions. > > But even with LDAP_SCHEMA_ALLOW_ALL the parsing chokes on e.g. > this line (Python exception instance displayed here): > > ldap.schema.SCHERR_NODIGIT: (5, "( pilotOrganization-OID NAME > 'pilotOrganization' DESC 'Standard ObjectClass' SUP 'top' MUST ( > objectclass $ ou $ o ) MAY ( aci $ buildingName $ > businessCategory $ description $ destinationIndicator $ > facsimileTelephoneNumber $ internationalIsdnNumber $ l $ > physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ > postalCode $ preferredDeliveryMethod $ registeredAddress $ > searchGuide $ seeAlso $ st $ street $ telephoneNumber $ > teletexTerminalIdentifier $ telexNumber $ userPassword $ > x121Address ) )") |