[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Move SLAPI in an overlay...
- To: ando@sys-net.it
- Subject: Re: Move SLAPI in an overlay...
- From: Luke Howard <lukeh@padl.com>
- Date: Fri, 22 Jul 2005 12:34:10 +1000
- Cc: openldap-devel@OpenLDAP.org
- Organization: PADL Software Pty Ltd
- References: <200507210047.j6L0lt9o084318@au.padl.com> <53994.131.175.154.56.1121923027.squirrel@131.175.154.56> <200507211555.j6LFtVfv042169@au.padl.com> <48676.131.175.154.56.1121962256.squirrel@131.175.154.56> <200507211630.j6LGUeg4044737@au.padl.com> <48871.131.175.154.56.1121963825.squirrel@131.175.154.56> <200507220052.j6M0qYvh072105@au.padl.com> <42E04BD7.9040307@sys-net.it>
- Versions: dmail (bsd44) 2.6d/makemail 2.10
>>We do, see slapi_over_response() in slapi/slapi_overlay.c (formerly
>>slapi_op_response()).
>
>I see. I wonder if calling slapi_int_call_plugins() without placing the
>original bd_info and be_private is appropriate.
I think a better solution, which I have working now, is to have
access_allowed() call frontendDB->bd_info->bi_access_allowed()
(which is ordinarily slap_access_allowed()) in the case that
the backend did not provide a bi_access_allowed implementation.
That allows global overlays to implement ACL checking.
-- Luke
--