I understand your point. From my first tests I was not able to reproduce
your case: as said before, LSC should never generate '\\,'. But testing
your other issue, I'm able to reproduce this issue with
getMainIdentifier().replace(). In this particular case,
getMainIdentifier() return the DN with \, escaping, while LSC handle it
internally with \2C.
So I confirm it is a bug, and we'll try to fix it. But it has nothing to
do with double escaping, which is fixed by using Rdn.escapeValue() and
which is already documented.
Regards,
Raphaël Ouazana.
Le 2014-12-17 17:51, Marian Harbach a écrit :
I will try that, but I think that LSC could be more resilient to such
“erroneous” scripts which would make it easier for users. Otherwise
you should be much more explicit about the requirements of the
javascript statements in the respective configuration parts. Otherwise
there will be many other people asking the same questions in the
future, because how am I supposed to know that I cannot simply use
replace() on getMainIdentifier() or that I can only use it in certain
situations.
Also, as I said in my previous mail, what if its not just
cn=Surname\\, Lastname,ou=Org,c=de but cn=Surname\,
Lastname,ou=Shipping\+Handling,c=de or even more complex cases where I
cannot just use getDatasetFirstValueById() with string addition to
create the main identifier?
I’ll get back to you tomorrow.
Marian
On 17. Dec 2014, at 17:25, Raphaël Ouazana-Sustowski
<[email protected]> wrote:
In fact LSC should already handle this case, and there should never be
a '\\,' value. I think this value is due to your erroneous script, not
to LSC way of handling DN.
Of course there were some bugs in LSC way of handling DN, so if you
still have the case with the fixed script, please submit it.
Regards,
Raphaël Ouazana.
Le 2014-12-17 16:49, Marian Harbach a écrit :
Hi, thanks for your answer. While this may be true (I'd have to check
if the value is really escaped differently in the cb attribute), this
solution will not help if there are escaped values in other RDNs of
the DN (we don't know how many RDNs and which there are in our DNs).
Marian
Am 17.12.2014 um 16:27 schrieb Raphaël Ouazana-Sustowski
<[email protected]>:
Hi,
Le 2014-12-12 23:54, Benjamin Henne a écrit :
Hi,
we have tried to implement what you mention in your link. However,
the
problems seems to persist. Here's the new mainIdentifier
construction:
<mainIdentifier>var pos =
srcBean.getMainIdentifier().indexOf(",OU=");
var cn =
srcBean.getMainIdentifier().substring(0,pos).split("=")[1];
I think your issue is here. Instead of trying to guess cn value
based on DN, you should take cn from source:
var cn = srcBean.getDatasetFirstValueById("cn")
var restDN =
srcBean.getMainIdentifier().substring(pos);
restDN = restDN.replace(",DC=de",",c=de");
var res =
"cn="+javax.naming.ldap.Rdn.escapeValue(cn)+restDN;
res</mainIdentifier>
Then the escaping would be fine here.
The first sync works fine. But when starting the second the error
that
occurs is as follows:
Dez 12 13:37:39 - ERROR - Error while synchronizing ID
cn=Lastname\\,
Firstname,ou=Benutzer,c=de: java.lang.RuntimeException:
org.apache.directory.api.ldap.model.exception.LdapInvalidDnException:
expecting EQUALS, found ','
# Fri Dec 12 13:37:39 CET 2014
dn: cn=Lastname\\, Firstname,ou=Benutzer,c=de
changetype: modrdn
newrdn: cn=Lastname\, Firstname
deleteoldrdn: 1
newsuperior: OU=Benutzer,c=de
So LSC continues to stack the escapes. When I look at the debugger
for
the above statement, the "res" variable contains the correct string
every time (both first and consecutive syncs). However, during the
second sync, the dstBean variable contains exactly this
double-escaped
version that is also seen in the above error message. Thus, I think
the problem is not in the construction of the MainIdentifier of the
srcBean, but in reading the main identifier of the dstBean from
OpenLDAP (which is not configurable as far as I understand it). As
I
wrote in my first post, AD and OpenLDAP seem to encode this
differently and therefore LSC finds a DN mismatch. Any help is
greatly
appreciated.
I think the double escaping is due to your script, not to LSC.
Regards,
Raphaël Ouazana.
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
