Why not a simple ACL for a group? Do the applications bind anonymously?

> A nicer approach would probably to have a hidden jpegPhoto: it would not > be sent to a client requesting all attributes, but a client explicitely > requesting a set of attribute including jpegPhoto would get it. I guess you will run into problems with some apps where you do want the jpegPhoto to be displayed.

With respect to your specific problem, you should be able to do something close to what you need by loading your jpegPhoto as jpegPhoto;x-mustberequested, then only allow access to this attribute and not to plain jpegPhoto.

Emmanuel Dreyfus wrote: > Michael Ströder <michael(a)stroeder.com&gt; wrote: > >> Why not a simple ACL for a group? Do the applications bind anonymously? > Of course it does. I said it was ill-designed :-) So why not point these ill-designed apps to a different DSA implemented by back-ldap with such an ACL? >>> A nicer approach would probably to have a hidden jpegPhoto: it would not >>> be sent to a client requesting all attributes, but a client explicitely >>> requesting a set of attribute including jpegPhoto would get it. >> I guess you will run into problems with some apps where you do want the >> jpegPhoto to be displayed. > Fortunately, the only apps I have that use the jpegPhoto are wise enough > to provide a set of attributes. AFAIK commonly used LDAP browsers never explicitly request jpegPhoto when displaying a *single* entry. My web2ldap explicitly limits the attrs to be returned when searching mutiple entries for not exhausting network bandwidth. But explicitly requesting binary attrs when displaying a single entry does not make sense for a generic LDAP client application. Off course if you're not using such application at all you won't have a problem. I think it would be interesting if an ACL could distinguish whether the search request has scope base and grant read access to jpegPhoto only in this case.

Michael Ströder <michael(a)stroeder.com&gt; wrote: > So why not point these ill-designed apps to a different DSA implemented > by back-ldap with such an ACL? Yes, that would work. It moves the setup to clients, with might be a bit more complicated to handle than the server for system administrators: there can be many clients, some of them you don't manage yourself.

The suggested "feature", on the contrary, seems to be a little bit more linear: the administrator decides that some attributes (e.g. bandwidth intensive ones) are not shown by default, unless explicitly requested. I see a parallel with soft and hard search limits: the soft limit applies, unless a specifically requested limit is present. In that case, the requested limit applies, provided it complies with the hard limit.