spring-ldap
spring-ldap copied to clipboard
Allowing LdapQueries with both fluent search and filter strings
I'm trying to use LdapQueryBuilder to create a complex query. I'd like to both apply a Filter string as well as do a fluent search.
However, the way the API is currently designed, you can't make complex searches. It appears that just making DefaultContainerCriteria public would allow this behavior; I don't know if there's a deeper reason not to do this.
Could you be more specific? What exactly do you mean by 'complex'? An example would be useful.
Cheers, Mattias
torsdag 13 augusti 2015 skrev Adam Campbell [email protected]:
I'm trying to use LdapQueryBuilder to create a complex query. I'd like to both apply a Filter string as well as do a fluent search.
However, the way the API is currently designed, you can't make complex searches. It appears that just making DefaultContainerCriteria public would allow this behavior; I don't know if there's a deeper reason not to do this.
— Reply to this email directly or view it on GitHub https://github.com/spring-projects/spring-ldap/issues/29.
The API allows for searching based on a filter (http://docs.spring.io/spring-ldap/docs/current/apidocs/org/springframework/ldap/query/LdapQueryBuilder.html#filter(java.lang.String)) or by fluent search (http://docs.spring.io/spring-ldap/docs/current/apidocs/org/springframework/ldap/query/LdapQueryBuilder.html#where(java.lang.String)). I'd like to use both.
An example of what this might look like: query().where("attribute").is("value").filter("filter") Why: I'd like to make a search (so fluent is the nice way to do this), but I'm also passed a filter from the outside world. I'd like to intersect the two searches.
Right, I see... Well, that won't be possible with the current API, and you might say that this is (semi-) by design. The thing is that the use of hardcoded filters is typically discouraged, particularly when it comes from the outside world. You should be very careful before using filters that come from user input, since this opens up for all sorts of evil stuff.
I do realise that's not much help for you here. Unfortunately, opening up the fluent interface for this won't be as easy as you suggest: Just allowing the filter() method to be called in the end wouldn't do much good since that would only replace the filter so far with a hardcoded one; in particular you would need some way to specify* how* the hardcoded filter would be combined to the rest (using & or |).
Doing this properly probably requires adding a number of methods to the API, so that you would be able to do e.g.: query().where("attribute").is("value").and(hardcoded("filter")) or query().where("attribute").is("value").and(new HardcodedFilter("filter"))
That would probably be possible, but I'm still not quite convinced that it would be a good idea (I haven't had that time to completely think through the consequences).
There is a workaround, but that would require you to use the "legacy" Filter API, e.g. something like this: AndFilter theFilter = new AndFilter(); theFilter.and(new EqualsFilter("attribute", "value")); theFilter.and(new HardcodedFilter("filter"));
query().filter(theFilter.encode());
Not as pretty as the fluent approach, but it would do the trick.
On Thu, Aug 13, 2015 at 10:23 PM, Adam Campbell [email protected] wrote:
The API allows for searching based on a filter ( http://docs.spring.io/spring-ldap/docs/current/apidocs/org/springframework/ldap/query/LdapQueryBuilder.html#filter(java.lang.String)) or by fluent search ( http://docs.spring.io/spring-ldap/docs/current/apidocs/org/springframework/ldap/query/LdapQueryBuilder.html#where(java.lang.String)). I'd like to use both.
An example of what this might look like: query().where("attribute").is("value").filter("filter") Why: I'd like to make a search (so fluent is the nice way to do this), but I'm also passed a filter from the outside world. I'd like to intersect the two searches.
— Reply to this email directly or view it on GitHub https://github.com/spring-projects/spring-ldap/issues/29#issuecomment-130829407 .
Forgot to respond: thanks so much, that works perfectly! The older API is great. It would be awesome if eventually the new API had feature parity.