Browse files

Removed part of the comments on ModifyDN. Net::LDAP encodes the messa…

…ge with newSuperior set to undef if we don't specify it in the options of moddn. Once encoded it doesn't get to the server in the message, so it's not a hack to find the base DN to which the newrdn is relative to since we cannot assume newSuperior is going to be in the moddn. This is the expected behaviour described in RFC 2251
  • Loading branch information...
1 parent 1948854 commit 0072673087e9cfa76f0e2cce531d5d5211c63f14 @rporres rporres committed Oct 25, 2012
Showing with 0 additions and 3 deletions.
  1. +0 −3 lib/Net/LDAP/Server/
@@ -525,9 +525,6 @@ Only one user-level method is implemented: new().
else {
# As we only have the new relative DN, we still
# need the base for it. We'll take it from $oldkey
- # This is somehow hackish, as the code of Net::LDAP
- # always define newSuperior in moddn operations and
- # it seems that it should always be defined
my $exploded_dn = ldap_explode_dn($oldkey, casefold => 'none');
shift @$exploded_dn;
$newkey .= ',' . canonical_dn($exploded_dn, casefold => 'none');

0 comments on commit 0072673

Please sign in to comment.