IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- The outside API contains "DN" string arguments: Bad. Since in this way we
fully rely on the outside calls regarding the right DN format. Solution: Use
always a "struct ldb_dn" entry. Since this one is interchangeable and we can
handle it in our preferred way.
- DN comparison: The function doesn't seem that efficient. I "upgraded" it a bit
to be more powerful (added a second length check and do both before the string
comparison)
When we rename or modify a record, we need to update the indexes at
the same time. It is important that we use the DN of the actual
message that is stored in the database to do this, not the DN that was
passed in by the user. If the two differ in case then the index
records needs to use the 'real' record DN, as index handling is
currently case sensitive.
When ildap created a new message to forward, it only copied controls for ldb_search
requests. This caused controls for add and modify to be lost in transition
and tests for them could not be implemented.
This specifically fixes a problem showing extra bytes of garbage in list and
print in regshell, even though the vk.data_length has the correct size.
Signed-off-by: Jelmer Vernooij <jelmer@samba.org>
Don't add only a new objectclass but also a new attribute. Plus let now the
server itself calculate the "lDAPDisplayName" attribute and compare the result.
The DN escape function was using the form \c where c is any
character. The unescape function was using \XX where XX is a 2 digit
hex number. The asymmetry led to quite a few problems when we start to
deal with DNs containing escape chars, such as CN=foo\0ADEL:XXX. The
result was a DN that was not accessible.
This patch changes the escaping to follow RFC2253 much more
closely. We accept either type of escape, and produce the two types of
escape, depending on the character being escaped
This is now in dsdb_dn. Removing this to a specific wrapper avoids a
number of bugs where Binary DNs were being handled incorrectly.
This reverts much of tridge's commit
fd22e0304782e20b9bbb29464b6c745d409ff4c6
Andrew Bartlett
This converts the code from using the binary DN code in ldb_dn to
using a special Samba-specfic wrapper around ldb_dn.
We also use the dsdb_dn code for DN+Binary and DN+String comparisons
(changed from treating them as Binary blobs)
Andrew Bartlett
Rather than have a repeat of the bugs we found at the plugfest where
hexidecimal strings must be in upper or lower case in particular
places, ensure that each caller chooses which case they want.
This reverts most of the callers back to upper case, as things were
before tridge's patch. The critical call in the extended DN code is
of course handled in lower case.
Andrew Bartlett
This size constraint is not correct in it's current form, as windows
does send us rDN values for CN with lengths longer than 64. Once we
know how this constraint really works we can add it back in.
This fixes up the broken "send" method of the python bindings and corrects some
other parameter lists in parsing functions (this is only cosmetic). The reason
for the bug was a superfluous "|"!
This helps pin down where errors occour, by printing a call stack and
setting error strings and trace messages in the transaction case.
Andrew Bartlett
The ldb_dn_explode code normally enforces all special characters,
including a '=', must be escaped. Unfortunately this conflicts with
the ltdb index DNs, which for binary attributes may be base64
encoded. This allows a unescaped '=' as a special case for index DNs.
I think this is better since "ldb_backend_connect" and "ldb_connect" which
propagate those values should return only LDB constants. Therefore a conversion
(especially for "-1") would be needed.
