Hallvard B Furuseth wrote:
Michael Ströder writes:
> Hallvard B Furuseth wrote:
>> Assertion controls in the generated LDIF, to check that the config entry
>> being updated indeed matches the entry we read from cn=config and
>> edited.
> BTW: web2ldap implements delta-modification. The entry is re-read right
> before the delta of the current entry and the user's input is generated.
> This works quite well since years with several LDAP servers. If there
> was a modification in between the delta modification still applies
> correctly.
Not sure if I should be writing this since I've hardly looked at
web2ldap yet, but anyway... I don't quite get that. I'd think a
correct delta would be generated by comparing with the entries as they
looked when the user started editing. Minus any changes that have
happened already. With back-config I would _not_ my changes to be
applied without asking me if there had been changes since I started
editing, hence my suggestion of assertions. A delta agains the current
directory would be useful to see if my own changes conflict in intent
with the changes that have already happened (regardless of whether my
changes would apply cleanly.)
web2ldap 0.16.26 now passes around a assertion filter for cross-checking
whether an entry was modified/removed in between. At the moment this is
only applied as a search filter when re-reading the entry to determine
the delta modification list.
I will also pass this assertion filter along with the modify request
once python-ldap supports the assertion control...
Ciao, Michael.