stoney core: ETag Mapping (REST - LDAP)
From stoney cloud
Overview
The idea of the ETag
is that one can edit/update resources without the changes made by somebody else.
Since the REST API may not be the only client to the LDAP and the REST API can't protect itself from concurrent writes to the LDAP on the same objects (due to the PHP principles of request-based execution), the LDAP must therefore most likely be part of the solution for generating and validating ETags.
Implementation proposal I
- fetch the internal LDAP attribute
csn
along with the object data - generate an ETag based on the value of the
csn
attribute by hashing it - return the ETag with the response to the REST client
- when receiving a
PUT
orPATCH
request, the client must return that ETag value - fetch the object again and generate the ETag using the newly fetched
csn
again - compare the ETag sent by the client and the generated one, break here if they do not match
- use LDAP Assertion Control when sending the edit request to the LDAP with the fetched
csn
as assertion
Implementation proposal II
- fetch the internal LDAP attribute
csn
along with the object data - generate an ETag based on the value of the
csn
attribute by encrypting it (and probably apply base64 transformation) - return the ETag with the response to the REST client
- when receiving a
PUT
orPATCH
request, the client must return that ETag value - decrypt the provided ETag value to retrieve the
csn
again - use LDAP Assertion Control when sending the edit request to the LDAP with the fetched
csn
as assertion
Notes:
- advantages: we hit the LDAP server less
- disadvantages: the length of the ETag depends directly on
csn
. What happens if we have multiple LDAP objects for one resource? - the security implications of this proposal are unclear