[Date Prev][Date Next]
Re: back-sql auxiliary objectClass attributes -> binary value syntax check?
> Having back-sql
What version of slapd?
> with iODBC and mysql deployed and set the debugging on,
> I realized that auxiliary objeclass(s) -those not mapped through
> ldap_entries.oc_map_id rather through ldap_entry_objclasses.oc_name-
> is only to represent the objectClass attribute of the main entry and a
> further attribute mapping fetch was not to be seen for those
> objectclasses in case they apply , although the ldap_oc_mappings and
> ldap_attr_mappings were properly configured.
Can you specify what the auxiliary objectClass has to do with it?
ldap_entry_objclasses contains the name of an objectClass that is
added to the structuralObjectClass; mapping of attributes for those
objectClasses must be done thru ldap_at_mapping -- even for those
attributes that do not fit in LDAP's schema for the
structuralObjectClass; schema checks are performed on the complete
ldap_entry_objclasses is a bit out of sync with the schema-aware
code of back-sql, it is mainly preserved not to break existing
deployments of back-sql but it will be probably removed in a future
major release of the software.
> Mapped those ldap_attr_mappings to some alternative main structural
> objectclass oc_map_id and using joins to acuxilary tables leads to
> retrieve the info but i am afraid the syntax checks will not be
> considered and it leads to not transporting binary information as binary
> rather as a hexdump string.
Do you mean that binary-valued attributes are not treated as blob's?
In fact, back-sql is assuming that attributes are strings.
A syntax-aware version is under consideration, but there are some
issues (mainly about portability).
> The actual case is person objectClass along with using pkiUser as an
> auxiliary objectClass holding the userCertificates and I used the
> inetOrgPerson as the alternative main objectClass.
> I already checked the odbc settings with test applications and the odbc
> driver delivers the db blob object in correct binary mode.
> Would somebody comment this and let me know how to force the binary
> transfer of those attributess or where is the right place to track that
> down why the transfer is done not in binary mode.
Assuming that you look at HEAD code (fixes or patches to earlier
releases are likely not to be considered), take a look at function
backsql_get_attr_vals() in entry-id.c; there's a comment about what
to do if an attribute has non-string syntax.
Note that back-sql in general has a type/syntax intrinsic problem,
because even string-like values in general should be converted from
whatever charset to utf8 and back. What is binary for SQL could be
something else for LDAP and vice-versa. A very special case is
represented by naming attributes and distinguished values (i.e.
those that participate in the DN).
I would ask you to separate the two issues:
a) auxiliary classes (if it is an issue at all)
b) searches returning binary values; this is a known issue that needs
be addressed. Patches are welcome.
I'd like to see the problem addressed in a general manner.