[1] Cookie: "#" $ ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL -E sync=ro/"#" [output snipped] Server returned all requested entries as if it would be without the cookie. [2] Cookie "##" $ ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL -E sync=ro/"##" Content Sync Refresh Required (4096) Additional information: Invalid session cookie [3] Cookie "a#a#a" $ ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL -E sync=ro/"a#a#a" [output snipped] Server returned all entries as if it would be without the cookie. [4] Cookie "a#a#1" $ ldapsearch -h localhost:389 ... -b dc=example,dc=com -LLL -E sync=ro/"a#a#1" Content Sync Refresh Required (4096) Additional information: Invalid session cookie In all cases cookie is invalid, but in [1] and [2] I get all requested entries, in [2] and [4] no entries at all. I think server should be more strict and return entries only when valid cookie is present or when there is no cookie at all.
Per 389-ds-base ticket triage, commented as: is this still valid? there has been more sanity checks on cookies likely fixed, but we should validate before closing.
The described behavior is still present in master branch. In fact the plugin is detecting the cookie is invalid, but by two different ways(and two different end results): parsing & validation
{{{ "#" - Fails parsing, but returns all entries "##" - Passes parsing, but fails validation check - error returned "a#a#a" - Fails parsing, but returns all entries "a#a#1" - Passes prasing, but fails validation check - error returned }}}
These separate parsing/validation steps just need to be done at the same time.
attachment 0001-Ticket-48013-Inconsistent-behaviour-of-DS-when-LDAP-.patch
71be5fa..fdf4681 master -> master commit fdf4681 Author: Mark Reynolds mreynolds@redhat.com Date: Wed Jul 8 17:21:57 2015 -0400
0680a45..41dff5b 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 41dff5b
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.4.2
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1344
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.