directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Commented] (DIRSERVER-2206) RefinementEvaluator fails when "objectClass" attribute is not present in the list of attributes
Date Tue, 22 Aug 2017 20:14:01 GMT


Emmanuel Lecharny commented on DIRSERVER-2206:

That being said, this is still a bug : the {{RefinementEvaluator}} should never throw an exception
in this case.

Now, to get it fixed, we have options, but they are not pleasant :
- first of all, we don't change anything in the way interceptors are executed, we simply return
{{false}} instead of throwing an exception, but that will not make the test working, assuming
the user wants the entries which have the {{person}} or {{inetOrgPerson}} Objectclasses. 
- Or we can change the way the {{authz}} interceptor works, by moving its filter higher in
the chain of search filters (like, before the {{schema}} interceptor filter). The problem
is that we will face some issues if one want to authorize based on some collective attributes
or operationnal attributes. This is tricky...

One solution would be to move the schema filter quite low in the chain (like, the last one
to apply), as it will transform the entry just before it sends them to the client. This is
what I would suggest to do. Note that it will require to pin the schema filter in the chain,
so that it's the last one, no matter what.

Any other idea ?

> RefinementEvaluator fails when "objectClass" attribute is not present in the list of
> -----------------------------------------------------------------------------------------------
>                 Key: DIRSERVER-2206
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 2.0.0-M24
>            Reporter: Kiran Ayyagari
>             Fix For: 2.0.0-M25
>         Attachments: allowreadusers.ldif
> I have a ACI that filters entries based on the the {{classes}} protected item but when
> the search request doesn't contain {{objectClass}} in the requested attributes the below
> exception is thrown.
> {noformat}
> ERR_296 objectClasses
cannot be null:
> java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at$200(
> 	at$AuthorizationFilter.accept(
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(
> 	at
> 	at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(
> 	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(
> 	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(
> 	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(
> 	at
> 	at
> 	at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(
> 	at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$
> 	at
> {noformat}
> Steps to reproduce:
> # Apply the allowreadusers.ldif
> # restart the server
> # run the command ldapsearch -H ldap://localhost:10389 -D "" -b "uid=kayyagari,ou=Users,dc=example,dc=com"
-s base -a always "(objectClass=*)" "uid"
> Note that if you request "objectClass" attribute along with "uid" then the request succeeds.

This message was sent by Atlassian JIRA

View raw message