[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: feature request (was: Re: Disallowing Wildcard Searches ?)

Norbert Klasen writes:

Hi Pierangelo,

--On Samstag, 23. Februar 2002 09:20 +0000 Pierangelo Masarati <masarati@aero.polimi.it> wrote: 

In HEAD code and in the forthcoming 2.1 alpha there's support
for granular check of the number of entries that are returned/handled;
in detail, you can set these limits based on the dn that initiated
the request (with subtree, regex and more matching clauses). The limits
can affect: the number of entries that are returned, the duration of
the operation, and (this is probably what you need) the number
of candidates that are checked (filter/acl) before returning.
By setting this limit to a reasonable value for non-authenticated
users you can obtain the filtering you need.

Would it be hard to implement limits based on the structural object class of an entry?
We are currently considering ways to provide LDAP access to the white-pages of the German reseach network (DFN AMBIX). To make it a bit harder for spammers to crawl the whole directory, we need to impose some server side limits. However, a global size limit is of little use here. While this would effectively reduce the number of person entries to be returned, it would also disallow browsing the DIT as container entries like l,o,ou are affected as well. What I'd like to do, is to only limit the number of 'person' entries to be returned.

In general, it would not be difficult. I had a (low priority) project
to make limits more general; they are currently handled based on the
dn of the operation, but, paralleling the ACLs, I was thinking about
IP/group[/set?] based limits. This on the side of the <who> clause.
With regard to the <what> clause, they're currently targeted at
size/time/candidates limiting, so changing their behavior might be a
little more difficult. To implement your suggestion, we should consider
a rule like

limit <what> by <who> <limit>

so a <what> of "structuralObjectClass=person" (we might implement it as
a filter style) by a <who> of "potentialSpammers" has a <limit> of
"size=<n>".

This requires some reworking of the limits, that is, besides "candidate"
type limits, before returning each entry we'd need to call a
limit_check(entry, op->o_ndn, ...) function with the entry as arg
In this case you get something similar to the size/time limits, that is
checked only __AFTER__ it's been passed, so it still loads your server.

Note the (implicit) <what> clause that's currently handled is
"objectClass=*", with <who> being "[dn[.<style>]=]<pattern>"
and <limit> being "[{time|size}[.<type>]=]<value>.

As a result, it looks like a nice TODO project (if there's enough
consensus on its usefulness).

Pierangelo.

Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati