By: Ivan Carrion user 31 Oct 2019 at 10:19 a.m. CDT

3 Responses
Ivan Carrion gravatar
We are on version 3.1.2 with a working custom LDAP filter: `(&(objectClass=user)(!(employeeID=GEN*))(employeeID=*))` We're trying to deploy version 4.0. When we try to put it on version 4.0, it throws us an exception: ``` 2019-10-31 15:17:12,402 ERROR [Thread-2755] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:207) - Exception happened while executing cache refresh synchronization java.lang.ArrayIndexOutOfBoundsException: 0 at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilterImpl(LdapFilterConverter.java:110) ~[oxcore-persistence-ldap-4.0.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilterImpl(LdapFilterConverter.java:106) ~[oxcore-persistence-ldap-4.0.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter.convertRawLdapFilterToFilter(LdapFilterConverter.java:94) ~[oxcore-persistence-ldap-4.0.Final.jar:?] at org.gluu.persist.ldap.impl.LdapFilterConverter$Proxy$_$$_WeldClientProxy.convertRawLdapFilterToFilter(Unknown Source) ~[oxcore-persistence-ldap-4.0.Final.jar:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshService.createFilter(CacheRefreshService.java:62) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.loadSourceServerEntriesWithoutLimits(CacheRefreshTimer.java:859) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.detectChangedEntries(CacheRefreshTimer.java:346) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processImpl(CacheRefreshTimer.java:302) ~[classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.processInt(CacheRefreshTimer.java:202) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer$Proxy$_$$_WeldSubclass.processInt(Unknown Source) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer.process(CacheRefreshTimer.java:185) [classes/:?] at org.gluu.oxtrust.ldap.cache.service.CacheRefreshTimer$Proxy$_$$_WeldSubclass.process$$super(Unknown Source) [classes/:?] at sun.reflect.GeneratedMethodAccessor268.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51) [weld-core-impl-3.1.1.Final.jar:3.1.1.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78) [weld-core-impl-3.1.1.Final.jar:3.1.1.Final] at org.gluu.service.cdi.async.AsynchronousInterceptor$1.get(AsynchronousInterceptor.java:36) [oxcore-service-4.0.Final.jar:?] at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590) [?:1.8.0_222] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222] ``` If we delete the filter, it works, but we don't want to refresh all the AD users allocated on the base dn. Please, help us. Thanks!

By Ivan Carrion user 31 Oct 2019 at 10:39 a.m. CDT

Ivan Carrion gravatar
update: If we put (&(objectClass=user)(employeeID=*)) it works. Maybe "!" symbol throws the error. I keep trying.

By Aliaksandr Samuseu staff 31 Oct 2019 at 12:39 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Ivan. Thanks for testing it. Please let us know about your future findings. I believe I tested a filter with `!` sign in it in earlier packages, and it worked back then.

By Ivan Carrion user 05 Nov 2019 at 9:24 a.m. CST

Ivan Carrion gravatar
I made tests around this issue and all LDAP filters work except those who have "!". We have solved it avoiding the use of that character (another valid filter generated to reduce the dataset), but I think you should review it.