use tmpmemctx for bsi_attrs (should be used more for temporaries)
fix ITS#3480: allow to fetch all attrs or provide hints
fixed access check to entry for rename
TODO: fetch entries for access checking in selected code portions (e.g. rename)
for further mucking with data. This can be of use in ill situations
where not all the required massaging can be done on data with SQL
by means of stored procedures, but overlays are called too early
and cannot be used to make data non LDAP compliant.
- only support for bidirectional DN mucking is provided right now
- support for other values mucking is planned
- write is not completely tested yet
- the API could change quite often; don't rely too much on it
other cleanup has been added.
- There might be special cases that require the unique key to be a string
(just ran into one); since this is not a generally useful change, it's
hidden behind #defines.
- Added essential support for telephoneNumber match; the same infrastructure
might be useful for other specialized matches (also regular matches should
use it to handle multiple spaces and so!).
- Fixed dynamic backend initialization.
- Cleaned up search base DN normalization (works also if no uppercase function
is available, using case exact matches).
to back-bdb, back-ldbm and back-sql (the latter with limitations);
- added handling of ":dn" attributes to extended rfc2254 filters
and to matched value filter
- altered the behavior of get_mra() when a matching rule is given:
now it checks whether it is compatible with the attribute syntax
and, in case it is, the given mr is used. In case of no type,
the check is delayed when filtering
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
