directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Commented] (DIRSERVER-1651) rfc 4533 implementation differences between openldap and apacheDS
Date Wed, 31 Aug 2011 20:26:10 GMT


Emmanuel Lecharny commented on DIRSERVER-1651:

We can simply follow OpenLDAP syntax for the cookie.

Now, there are some interesting chapter (7) in RFC 4533 :

"   Implementors should take precautions against malicious cookie
   content, including malformed cookies or valid cookies used with
   different security associations and/or protections in an attempt to
   obtain unauthorized access to information.  Servers may include a
   digital signature in the cookie to detect tampering."

I just wonder if we should not add some additional information at the end of the cookie, an
opaque one.

if we assume the cookie format is :
rid=<replicaId>[,csn=<Csn value>]

we can also add :
rid=<replicaId>[,csn=<Csn value>][,signature=<signature>]

> rfc 4533 implementation differences between openldap and apacheDS
> -----------------------------------------------------------------
>                 Key: DIRSERVER-1651
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: ldap
>    Affects Versions: 2.0.0-M2
>            Reporter: Hajo Kliemeck
>              Labels: 4533, openldap, syncrepl
> Tthere is an incompatibility between the RFC 4533 implementation of apacheDS and openldap.
> openldap uses the cookie structure "rid=<replicaId>" (initial) or "rid=<replicaId>,csn=<Csn
value>" (update) while apacheDS is using NULL for the initial state and the structure "<replicaId>;<Csn
value>" for the update state. in the RFC its said:
> {quote}
> The absence of a cookie or an initialized synchronization state in a cookie indicates
a request for initial content.....
> {quote}
> first is apacheDS like, second is openldap like
> It should be possible to adapt the structure or the behavior.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message