Re: disable simple paged results control support?!

[Igor Shmukler <igor.shmukler@gmail.com>]

Hello Aaron,

Thank you for responding.
I am still trying to process your email. Hopefully, I understand some
of your suggestions. Thank you for referring me to test025.
I would be delighted to get: "Unavailable Critical Extension" in
return for simple paged results request.
My problem is that the server does not return anything reflecting that
paged results control is disabled. Please take a look:
# search result
search: 4
result: 0 Success
control: 1.2.840.113556.1.4.319 false MA0CAQAECA8AAAAAAAAA
pagedresults: cookie=DwAAAAAAAAA=
# extended LDIF
#
# LDAPv3
# base <dc=sssvlv,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with pagedResults critical control: size=5
#

# ffanco, sssvlv.com
dn: cn=ffanco,dc=sssvlv,dc=com
sn: Fanco
ipPhone: 20006
givenName: Franc
mail: ffanco@spain.gov.es

Hence, my question is whether I did something wrong while attempting
to disable paged results.

Sincerely,

Igor Shmukler

On Thu, Aug 27, 2015 at 4:37 PM, Aaron Richton <richton@nbcs.rutgers.edu> wrote:
> On Thu, 27 Aug 2015, Igor Shmukler wrote:
>
>> olcSizeLimit: size.prtotal=disabled
>>
>> What is wrong with the LDIF? It was successfully applied using
>> ldapmodify(1), yet my server still does not throw an unsupported
>> control, instead providing clients with paged results.
>
>
> You can see how prtotal=disabled is supposed to work with test025, e.g.
>
> $ ../clients/tools/ldapsearch -P 3 -x -S uid -b 'dc=example,dc=com' -h
> localhost -p 9011 -w secret -D 'cn=Paged Results Disabled User,ou=Paged
> Results Users,dc=example,dc=com' -E '!pr=5/noprompt' -b 'dc=example,dc=com'
> '(objectClass=*)'
> # extended LDIF
> #
> # LDAPv3
> # base <dc=example,dc=com> with scope subtree
> # filter: (objectClass=*)
> # requesting: ALL
> # with pagedResults critical control: size=5
> #
>
> # search result
> search: 2
> result: 11 Administrative limit exceeded
> text: pagedResults control not allowed
>
> # numResponses: 1
>
>
> so perhaps turn up your slapd logging and see if you're sending that result.
> And you mention "unsupported control," but these are administrative limits,
> it's not like this deletes the code from slapd. For example again with
> test025 and assuming you don't --enable-sssvlv=yes:
>
> $ ../clients/tools/ldapsearch -P 3 -x -S uid -b 'dc=example,dc=com' -h
> localhost -p 9011 -E '!sss=mail:caseIgnoreIA5Match' -b 'dc=example,dc=com'
> '(objectClass=*)'
> # extended LDIF
> #
> # LDAPv3
> # base <dc=example,dc=com> with scope subtree
> # filter: (objectClass=*)
> # requesting: ALL
> # with server side sorting critical control
> #
>
> # search result
> search: 2
> result: 12 Critical extension is unavailable
> text: critical extension is not recognized
>
> # numResponses: 1
>
>
> Note that one practical, albeit somewhat evil, method to deal with confused
> clients can be to disallow them access to the supportedControl.
>
> # VLV, for instance
> access to dn.exact=""
>         attrs=supportedControl
>         val/objectIdentifierMatch.exact=2.16.840.1.113730.3.4.9
>         by <foolishClient> none