Ok, I get a fixed version of the setFilter( String ) that produces this
output:
<?xml version="1.0" encoding="UTF-8"?>
<batchRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<searchRequest derefAliases="derefAlways">
<filter>
<equalityMatch name="uid">
<value/>
</equalityMatch>
<equalityMatch name="uid">
<value
xsi:type="xsd:base64Binary">U29tZUFyYml0cmFyeUJlbmlnblN0cmluZw==</value>
</equalityMatch>
</filter>
</searchRequest>
</batchRequest>
As youc an imagine, "U29tZUFyYml0cmFyeUJlbmlnblN0cmluZw==" is
"SomeArbitraryBenignString" base 64 encoded.
Should it do the trick?
On 05/12/2023 15:43, Patrick Peer wrote:
Thanks Emmanuel!
Using a SchemaManager solved my immediate problem. However, now I need
to provide a custom Schema, since I need to query domain specific OIDs.
Before, the library was happy with arbitrary OIDs, and so was I :).
Addressing the easy API life,
org.apache.directory.api.dsmlv2.request.SearchRequestDsml.setFilter(String) seems broken to me, as this code path does not produce the expected output, and this is not obvious in any way, not to say that the semantic of this method changed without notice. Ideally, this method would not exist, but since it is required by the implemented interface, that is not easily achieved, and a bigger refactoring would be needed. That said, I, of course, do not have a deep understanding of your code base, so please take my suggestion with a grain of salt ;).
Thanks for the improved setFilter(SchemaManager, String) method, albeit
it is secondary to me, compared to the changed semantics of
setFilter(String), and the extra setup needed to be able to query
arbitrary OIDs. To better illustrate what I mean, here is one of the
filters which is currently broken for me:
"(hcIdentifier=*1.3.6.1.4.1.21367.1776:IHENA:A-919191:Active*)"
I am currently in the process of figuring out an easy way to add the
required OIDs to the SchemaManager, and will eventually figure it out,
but if you have any hints, I'd be grateful :).
Cheers,
Patrick
Am Di., 5. Dez. 2023 um 13:48 Uhr schrieb Emmanuel Lécharny
<[email protected] <mailto:[email protected]>>:
Hi again!
I have modified the LDAP API to be able to deal with the attributeType
properly when we have a SchemaManager, and to do so in a more user
friendly way.
Here is thge modified original test:
@Test
public void testMinimalEqualityRequest() throws Exception {
SearchRequestDsml searchRequest = new
SearchRequestDsml(LdapApiServiceFactory.getSingleton());
// Create the SchemaManager instance
SchemaManager schemaManager = new DefaultSchemaManager();
// Use it as a parameter so that the filter get properly parsed
searchRequest.setFilter( schemaManager,
"(uid=SomeArbitraryBenignString)" );
BatchRequestDsml batchRequest = new BatchRequestDsml();
batchRequest.addRequest(searchRequest);
String dsmlString = batchRequest.toDsml();
System.out.print( dsmlString );
}
which prints out the expected result:
<?xml version="1.0" encoding="UTF-8"?>
<batchRequest>
<searchRequest derefAliases="derefAlways">
<filter>
<equalityMatch name="uid">
<value>SomeArbitraryBenignString</value>
</equalityMatch>
</filter>
</searchRequest>
</batchRequest>
It will most certainly be included in 2.1.6.
On 04/12/2023 21:18, Patrick Peer wrote:
> Hello!
>
> I recently upgraded the version
of org.apache.directory.api:api-all from
> 2.1.0 to 2.1.5 in the dependencies of our product, which resulted in
> some test failures on my end. As it seems, values for equality
filters
> are not set in the request anymore. For your convenience, I cobbled
> together a minimal test case to reproduce the condition [1].
It works
> with Version 2.1.0 and does not work with 2.1.5.
>
> Upon further investigation, I think I found some issues
>
in
org.apache.directory.api.dsmlv2.request.SearchRequestDsml.toDsml(Element,
ExprNode)@2.1.5:
> + On line 559 value.isHumanReadable() is queried to decide
whether to
> use the value as is, or to encode it in base64. => This seems
broken,
> since, as far as I can tell,
> the org.apache.directory.api.ldap.model.entry.Value.isHR flag is
always
> false at this particular point in the code.
>
+ org.apache.directory.api.dsmlv2.ParserUtils.base64Encode(Object) only
> yields base64 values for byte[] and String, however here a
> org.apache.directory.api.ldap.model.entry.Value is passed, which
will
> always result in an empty String.
>
> The corresponding commit should be [2].
>
> Do you agree that this is a bug, and should I jump through the
hoops to
> open a Jira issue, or is there an alternative/intended way to work
> around this?
>
> Cheers,
> Patrick Peer
>
>
>
> [1]
> @Test
> public void testMinimalEqualityRequest() throws Exception {
> SearchRequestDsml searchRequest = new
> SearchRequestDsml(LdapApiServiceFactory.getSingleton());
> searchRequest.setFilter("(uid=SomeArbitraryBenignString)");
>
> BatchRequestDsml batchRequest = new BatchRequestDsml();
> batchRequest.addRequest(searchRequest);
> String dsmlString = batchRequest.toDsml();
>
> assertThat(dsmlString).contains("SomeArbitraryBenignString");
> }
>
> [2]
>
https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
[email protected] <mailto:[email protected]>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
