[
https://issues.apache.org/jira/browse/DIRSERVER-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16137314#comment-16137314
]
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 attributes
> -----------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-2206
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2206
> 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}
> org.apache.directory.api.ldap.model.message.SearchRequestImpl@c452319:
> ERR_296 objectClasses cannot be null:
> java.lang.IllegalArgumentException: ERR_296 objectClasses cannot be null
> at
> org.apache.directory.server.core.api.subtree.RefinementEvaluator.evaluate(RefinementEvaluator.java:65)
> at
> org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.isRelated(RelatedProtectedItemFilter.java:213)
> at
> org.apache.directory.server.core.authz.support.RelatedProtectedItemFilter.filter(RelatedProtectedItemFilter.java:86)
> at
> org.apache.directory.server.core.authz.support.ACDFEngine.hasPermission(ACDFEngine.java:160)
> at
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.filter(AciAuthorizationInterceptor.java:1368)
> at
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor.access$200(AciAuthorizationInterceptor.java:91)
> at
> org.apache.directory.server.core.authz.AciAuthorizationInterceptor$AuthorizationFilter.accept(AciAuthorizationInterceptor.java:1428)
> at
> org.apache.directory.server.core.api.filtering.EntryFilteringCursorImpl.next(EntryFilteringCursorImpl.java:454)
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.writeResults(SearchRequestHandler.java:380)
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.doSimpleSearch(SearchRequestHandler.java:840)
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleIgnoringReferrals(SearchRequestHandler.java:1164)
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handleWithReferrals(SearchRequestHandler.java:1258)
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:212)
> at
> org.apache.directory.server.ldap.handlers.request.SearchRequestHandler.handle(SearchRequestHandler.java:92)
> at
> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:222)
> at
> org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56)
> at
> org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:243)
> at
> org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:216)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
> at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
> at
> org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
> at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
> at
> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:476)
> at
> org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:430)
> at java.lang.Thread.run(Thread.java:745)
> {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
(v6.4.14#64029)
