directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Attribute filtering handling...
Date Tue, 11 Dec 2012 10:02:48 GMT
On Tue, Dec 11, 2012 at 3:23 PM, Emmanuel L├ęcharny <elecharny@gmail.com>wrote:

> Hi !
>
> I spent some time those past two days checking the way we are processing
> the filtering of attributes when doing a search or a lookup. A new
> OperationContext class has been created to merge the common elements
> from the lookup, search and list operation. So far, so good.
>
> Still, while adding some new tests, I saw that we still have issues :
> - we can't do a lookup and filter the attributes, we don't get back
> inherited attrs (like 'cn' or 'sn' when filtering using 'name')
> - we do the filtering in many places (SchemaInterceptor,
> AbstractBtreePartition, OperationalAttribute)
> - we create too many lists in the middle for the sake of managing the
> returned attributes
>
> Basically, we have to follow a list of rules :
> o when we have a '*' in the list, we should return all the user
> attributes. We don't mind if we have some user attributes in the list,
> they will be ignored
> o when we have a '+' in the list, we should return all the operational
> attributes. We don't mind if we have some operational attributes in the
> list, they will be ignored
> o if we have either a '+', a '*' or any attribute in the list, then we
> should ignore the '1.1' attribute
> o if we have no attributes, no '*', no '+', no '1.1', then '*' is
> assumed to be present
> o when we have any attribute in the list, not shadowed by the '*' or '+'
> attributes, then we should return any attribute which chain of superior
> contain one of the give attribute (ie, having 'name' in the list will
> allow 'cn', 'sn', and every attribute which superior is 'name' to be
> returned'
>
> The four first rules can be enforced when we process the incoming
> request and create the OperationContext. We will then just have either a
> list of attributes naked (no '+', '*' or '1.1'), or a lits of attributes
> with either '+' or '*', or just '+' and/or '*', or '1.1'.
>
> Once this preliminary work is done, we can now filter the attributes
> where it's needed (and it's not in the backend, because some attributes
> may be added after we get back the entry from the backend : typically,
> the entryDn attribute, or any collective attribute, or some potential
> virtual attributes).
>
> Considering the list of interceptors, and their order :
>  - NormalizationInterceptor
>  - AuthenticationInterceptor
>  - ReferralInterceptor
>  - AciAuthorizationInterceptor
>  - DefaultAuthorizationInterceptor
>  - AdministrativePointInterceptor
>  - ExceptionInterceptor
>  - SchemaInterceptor
>  - OperationalAttributeInterceptor
>  - CollectiveAttributeInterceptor
>  - SubentryInterceptor
>  - EventInterceptor
>  - TriggerInterceptor
>  - ChangeLogInterceptor
>  - JournalInterceptor
>
> the best place to do this filtering is probably in the SchemaInterceptor.
>
> But, and there is a big but, when processing a search request, we do a
> direct lookup from the backend, and we are not going through this chain.
> What happens is that we are building a list of filters, and we apply
> this list of filters on every entry fetched from the backend doing a
> direct lookup. So the filter added by the SchemaInterceptor should also
> do this filtering.
>
> as the filtering is only applicable for search(and lookup) why not apply
this logic in the cursor
after evaluating an entry, I know that this filtering logic was scattered
before but with all that
moved to a utility class I think using that inside the cursor is the right
thing rather than doing it in an
interceptor

> I don't think I have missed anything in this analysis, but if so, please
> feel free to correct me !
>
> Side note : I wonder if we shouldn't add a VirtualAttributeInterceptor
> to process any virtual attributes, like the EntryDn. This interceptor
> could be added after the SchemaInterceptor in the chain. wdyt ?
>
> nooo  :) let us add this when we support more than one virtual attribute

thanks Emmanuel for the detailed information

> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message