Now related ITSes need be audited and possibly closed.
Enhancements:
- re-styled code for better readability
- upgraded backend API to reflect recent changes
- LDAP schema is checked when loading SQL/LDAP mapping
- AttributeDescription/ObjectClass pointers used for more efficient
mapping lookup
- bervals used where string length is required often
- atomized write operations by committing at the end of each operation
and defaulting connection closure to rollback
- added LDAP access control to write operations
- fully implemented modrdn (with rdn attrs change, deleteoldrdn,
access check, parent/children check and more)
- added parent access control, children control to delete operation
- added structuralObjectClass operational attribute check and
value return on search
- added hasSubordinate operational attribute on demand
- search limits are appropriately enforced
- function backsql_strcat() has been made more efficient
- concat function has been made configurable by means of a pattern
- added config switches:
- fail_if_no_mapping write operations fail if there is no mapping
- has_ldapinfo_dn_ru overrides autodetect
- concat_pattern a string containing two '?' is used
(note that "?||?" should be more portable
than builtin function "CONCAT(?,?)")
- strcast_func cast of string constants in "SELECT DISTINCT statements (needed by PostgreSQL)
- upper_needs_cast cast the argument of upper when required
(basically when building dn substring queries)
Todo:
- add security checks for SQL statements that can be injected (?)
- re-test with previously supported RDBMs
- replace dn_ru and so with normalized dn (no need for upper() and so
in dn match)
- implement a backsql_normalize() function to replace the upper()
conversion routines
- note that subtree deletion, subtree renaming and so could be easily
implemented (rollback and consistency checks are available :)
- implement "lastmod" and other operational stuff (ldap_entries table ?)
- now all write operations appear to work correctly with PostgeSQL 7.0
- all write operations have been made transactional (atomic writes to
entries are committed separately only in case of complete^1 success
while all other operations are rolled-back by default)
- more cleanup and handling of exceptional conditions
TODO:
- deen to check with different databases and more up to date versions
of both unixODBC and PostgreSQL.
^1: attribute add/modify/delete operations silently succeed if the
appropriate add/delete proc does not exist for each attribute;
this may be correct to hide undesired/unimplemented correspondence
between LDAP and SQL databases; however, a more appropriate
LDAP behavior would be a failure with LDAP_UNAVAILABLE if a
single write operation cannot be executed for such reason
