You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Patrick Peer <p....@synedra.com> on 2023/12/04 20:18:17 UTC
Serialization of equality filters broken?
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
Re: Serialization of equality filters broken?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Patrick,
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 :).
Understood. The thing is that the API is either schema-aware, or not. If
not (the normal way of handling things), we based our attributes
handling on this RFC section:
https://datatracker.ietf.org/doc/html/rfc2252#section-4.3.2
Basically, everything that is not explicitely h-r (Human Readable) is
now considered as binary.
>
> 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.
The semantic has not changed, the result has changed!
Btw, I now realize that the output is incorrect, even after my fix. The
produced DSML should still contain the Base64 value, which is currently
not. I'll fix that.
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.
My guess is that you should be able to use the setFilter(String) which
would produce the proper DSML document, with the value encoded in Base64
if the Attribute is not known.
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 ;).
Well, it's a bit complex, as you can imagine :-) Probably too complex,
but it was made to be efficient (aka fast) because it's deeply used in
the Apache Directory Server.
Enough said that a Filter is a set of Attribute + values, and that
Attributes have a type, which is associated with a Syntax, and some
other things that are badly needed when doing some filtering
(Normalizers, Comparators, SyntaxCheckers). Each one of those elements
are associated with the AttributeType, which is pulled from the
SchemaManager when you do a lookup using an Attribute OID.
If the OID does not exist in the SchemaManager, then we can't do
comparison, we can't check the syntax, we can't normalize the value
(normalization is quite a complex process that is described in
https://datatracker.ietf.org/doc/html/rfc4518). Now, on the client side,
we don't really mind, because we just construct the filter as a string,
and pass it to the server, which will deal with it...
Whatever, time to get the setFilter(String) to work, and produce the
proper DSML output :-)
Side note: I'd be interested to know what is your usage of the LDAP API
and why you picked it against other libs. Just for my personnal interest!
>
> 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
> <elecharny@gmail.com <ma...@gmail.com>>:
>
> 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
> elecharny@apache.org <ma...@apache.org>
>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecharny@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Serialization of equality filters broken?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Patrick,
(please keep dev@directory.a.o as a recipient, other people might be
interested in this discussion)
Actually, a search filter can be converted into a String, per RFC 4515
[1], so yes, we could keep the String as a String instead of switching
to a Base64 encoded String.
I must say that the conversion to a Base64 encoded String was convenient
for us, but that might be a burden in many cases.
Switchijg to something that is not base64 encoded should not be a big
burden for the API (actually, probably a one liner).
[1] (https://datatracker.ietf.org/doc/html/rfc4515)
On 09/02/2024 08:58, Patrick Peer wrote:
> Emmanuel,
>
> no worries, as far as I can tell, your code is correct ;). The attribute
> xsi:type="xsd:base64Binary" is generated correctly in the request I sent
> [2]. However, the simulator seems to ignore/drop this attribute [1] when
> interpreting the request, which should bug in the simulator. I'd share a
> link to that discussion, but unfortunately it is not public :/.
>
> Even though your solution is correct, I'd like to know if you can
> imagine to preserve the original string, because in this specific case
> the api call
> SearchRequestDsml searchRequest = new
> SearchRequestDsml(LdapApiServiceFactory.getSingleton());
>
> searchRequest.setFilter("(memberOf=cn=MercyCenterHospitalGroup,ou=Relationship,dc=HPD,o=IHE-Europe,c=FRA)");
> leads to
> <value
> xsi:type="xsd:base64Binary">Y249TWVyY3lDZW50ZXJIb3NwaXRhbEdyb3VwLG91PVJlbGF0aW9uc2hpcCxkYz1IUEQsbz1JSEUtRXVyb3BlLGM9RlJB</value>
> in the request.
>
> In other words, do you think the conversion to a byte array within the
> library (and consequently the base64 encoding) could be avoided for
> string filters?
>
>
> Thanks,
> Patrick
>
>
> [1]
> https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572 <https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572>
> [2]
> <?xml version="1.0" encoding="UTF-8" standalone="no"?><env:Envelope
> xmlns:env="http://www.w3.org/2003/05/soap-envelope
> <http://www.w3.org/2003/05/soap-envelope>">
> <env:Header>
> <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing
> <http://www.w3.org/2005/08/addressing>">https://gazelle.synedra.lan/HPDSimulator-ejb/ProviderInformationDirectory_Service/ProviderInformationDirectory_PortType <https://gazelle.synedra.lan/HPDSimulator-ejb/ProviderInformationDirectory_Service/ProviderInformationDirectory_PortType></wsa:To>
> <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing
> <http://www.w3.org/2005/08/addressing>">urn:uuid:3498c2e0-45c0-402a-bfc3-e289ee3afaef</wsa:MessageID>
> <wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing
> <http://www.w3.org/2005/08/addressing>">
> <wsa:Address>"
> title="http://www.w3.org/2005/08/addressing/anonymous
> <http://www.w3.org/2005/08/addressing/anonymous>"
> target="_blank">http://www.w3.org/2005/08/addressing/anonymous
> <http://www.w3.org/2005/08/addressing/anonymous></wsa:Address>;
> </wsa:ReplyTo>
> <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing
> <http://www.w3.org/2005/08/addressing>"
> env:mustUnderstand="1">urn:ihe:iti:2010:ProviderInformationQuery</wsa:Action>
> </env:Header>
> <env:Body>
> <batchRequest xmlns="urn:oasis:names:tc:DSML:2:0:core"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>">
> <searchRequest derefAliases="derefAlways"
> dn="ou=HCProfessional,dc=HPD,o=gazelle,c=IHE" requestID="1"
> scope="wholeSubtree">
> <filter>
> <equalityMatch name="memberOf">
> <value
> xsi:type="xsd:base64Binary">Y249TWVyY3lDZW50ZXJIb3NwaXRhbEdyb3VwLG91PVJlbGF0aW9uc2hpcCxkYz1IUEQsbz1JSEUtRXVyb3BlLGM9RlJB</value>
> </equalityMatch>
> </filter>
> <attributes>
> <attribute name="cn"/>
> <attribute name="objectClass"/>
> <attribute name="hcIdentifier"/>
> <attribute name="o"/>
> <attribute name="hcRegisteredName"/>
> <attribute name="hpdProviderPracticeAddress"/>
> <attribute name="displayName"/>
> <attribute name="physicalDeliveryOfficeName"/>
> <attribute name="uid"/>
> <attribute name="individualProviders"/>
> <attribute name="prRelationId"/>
> <attribute name="prHasAProviderFrom"/>
> <attribute name="prHasAProviderTo"/>
> <attribute name="prRelationRole"/>
> </attributes>
> </searchRequest>
> </batchRequest>
> </env:Body>
> </env:Envelope>
>
> Am Do., 8. Feb. 2024 um 20:24 Uhr schrieb Emmanuel Lécharny
> <elecharny@gmail.com <ma...@gmail.com>>:
>
> Ok so some more info:
>
> The memberOf attribute is a bit special. It's first a AcriveDirectory
> Attribute and its syntax is Distinguish Name Syntax. Which means it's
> not purely a String, which is the reason it's base64 encoded.
>
> Whe it comes to encode values, the following rule should apply:
>
> "When creating DSML messages, all Attributes whose value is Java byte
> array are Base64 encoded to String before being written in the DSML
> message.
>
> If when creating a DSML message an Attribute is passed whose value's
> type is neither String nor Java byte array, the value is converted to
> String by calling the object's "toString()" method and this String
> value
> is written in the DSML message.
> "
> (that is from IBM).
>
> OASIS is a bit more light when it comes to tell what should be base64
> encoded or not:
>
> "The definition of DsmlValue permits the following types: UTF-8,
> base64Binary, and any URI."
>
> Now, to be able to know what would be the value type, there is some
> attribute that needs to be added:
>
> xsi:type="xsd:base64Binary"
>
> Like in :
>
> <control type="1.2.840.113556.1.4.612" criticality="true">
> <controlValue xsi:type="xsd:base64Binary">
> U2VhcmNoIFJlcXVlc3QgRXhhbXBsZQ==
> </controlValue>
> </control>
>
>
> So I guess we should avoid ommitting this attribute when base64
> encoding
> a value.
>
> On 08/02/2024 18:11, Emmanuel Lecharny wrote:
> > Hi Patrick,
> >
> > I have to check why the value gets base64 encoded. I thought the
> issue
> > was already properly addressed (see
> >
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369 <https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369>
> >
> <https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369 <https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369>>)
> >
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com <http://www.iktek.com> <http://www.iktek.com
> <http://www.iktek.com>>
> >
> >
> > Le jeu. 8 févr. 2024 à 16:22, Patrick Peer <p.peer@synedra.com
> <ma...@synedra.com>
> > <mailto:p.peer@synedra.com <ma...@synedra.com>>> a écrit :
> >
> > Hi Emmanuel!
> >
> > I finally got around to upgrading to the newest version. The good
> > news: The value for the equalityMatch is generated
> successfully. The
> > bad news: IHE's HPD simulator [1] seems to have problems with the
> > base64 encoding. It seems as if the xsi:type-Attribute is not
> > recognized and/or dropped [2].
> > Now, I think the request should be correct in the context of
> > HPD-queries, and that the simulator is clumsy. I will hash
> that out
> > with the folks at IHE. However, this leads me to think that other
> > "real" implementations of HPDs will have problems with
> base64, too.
> >
> > I will now have to decide with my colleagues how to handle
> this. One
> > possibility would be to generate the normal strings again. To do
> > that, I could compile a modified version of the library myself
> > (luckily I could get away with breaking the code for parsing
> > requests, should that be an issue, as you hinted before).
> Still, I'd
> > like to know how you think about reverting to generating
> strings in
> > the official library again. At least for the case, when the
> value is
> > a string to begin with, and a conversion to base64 would not be
> > required.
> >
> > In any case, thanks for the fix :)!
> >
> > Cheers,
> > Patrick
> >
> > [1] https://gazelle.ihe.net/HPDSimulator/home.seam
> <https://gazelle.ihe.net/HPDSimulator/home.seam>
> > <https://gazelle.ihe.net/HPDSimulator/home.seam
> <https://gazelle.ihe.net/HPDSimulator/home.seam>>
> > [2]
> >
> https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572 <https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572> <https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572 <https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572>>
> >
> > Am Di., 6. Feb. 2024 um 08:52 Uhr schrieb Emmanuel Lécharny
> > <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>:
> >
> > Hi,
> >
> > the release has been voted. It's available. Enjoy!
> >
> > On 02/02/2024 12:05, Patrick Peer wrote:
> > > Thank you very much! Much appreciated :).
> > >
> > > Am Fr., 2. Feb. 2024 um 10:41 Uhr schrieb Emmanuel
> Lécharny
> > > <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>>:
> > >
> > > The release is being voted. I expect to be out at the
> > beginning of next
> > > week.
> > >
> > > On 29/01/2024 14:03, Patrick Peer wrote:
> > > > Emmanuel,
> > > >
> > > > can you give me a rough estimate on when a new
> version
> > with the
> > > fixes
> > > > will be available? I need to upgrade due to
> CVEs for
> > dependencies of
> > > > older versions of org.apache.directory.api:api-all,
> > for the
> > > release of
> > > > our own software. Thus I need to know whether I can
> > wait for your
> > > > release, or need to compile the library myself.
> > > >
> > > > Cheers,
> > > > Patrick
> > > >
> > > > Am Mi., 6. Dez. 2023 um 09:26 Uhr schrieb
> Patrick Peer
> > > > <p.peer@synedra.com <ma...@synedra.com>
> <mailto:p.peer@synedra.com <ma...@synedra.com>>
> > <mailto:p.peer@synedra.com <ma...@synedra.com>
> <mailto:p.peer@synedra.com <ma...@synedra.com>>>
> > > <mailto:p.peer@synedra.com
> <ma...@synedra.com> <mailto:p.peer@synedra.com
> <ma...@synedra.com>>
> > <mailto:p.peer@synedra.com <ma...@synedra.com>
> <mailto:p.peer@synedra.com <ma...@synedra.com>>>>>:
> > > >
> > > > Hi Emmanuel!
> > > >
> > > > > Side note: I'd be interested to know what is
> > your usage of the
> > > > LDAP API
> > > > > and why you picked it against other
> libs. Just
> > for my
> > > personnal
> > > > interest!
> > > > I inherited the code using the LDAP API, so my
> > best guess is:
> > > When
> > > > Apache provides a library for the thing you
> want
> > to do, you
> > > use it :).
> > > > As for the actual use case, we want to query
> > Healthcare Provider
> > > > Directories (HPDs) [1].
> > > >
> > > > > Btw, I now realize that the output is
> > incorrect, even after my
> > > > fix. The
> > > > > produced DSML should still contain the
> Base64
> > value, which is
> > > > currently
> > > > > not. I'll fix that.
> > > > Given that this was a bug, and the filter
> values
> > will be
> > > generated
> > > > again, setFilter(String) _should_ work
> after the fix.
> > > However, given
> > > > my experience in the field, I fear there
> will be
> > problems
> > > with HPDs
> > > > that are not prepared to handle base64
> values. I
> > might be
> > > wrong on
> > > > that though, and as long as IHE's HPD
> simulator is
> > happy, I
> > > think I
> > > > will use the simpler (for me) base64
> filters. On
> > that note,
> > > do you
> > > > have an estimate on when a new version will be
> > released?
> > > >
> > > > Cheers,
> > > > Patrick
> > > >
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>>> - 3.58 Provider Information Query
> > > >
> > > > Am Di., 5. Dez. 2023 um 23:02 Uhr schrieb
> Emmanuel
> > Lécharny
> > > > <elecharny@gmail.com
> <ma...@gmail.com> <mailto:elecharny@gmail.com
> <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>
> > > <mailto:elecharny@gmail.com
> <ma...@gmail.com> <mailto:elecharny@gmail.com
> <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>>>:
> > > >
> > > > 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
> <http://www.w3.org/2001/XMLSchema>
> > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>>
> > > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>
> > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>>>
> > > > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>
> > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>>
> > > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>
> > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>>>>"
> > > >
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>
> > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>>
> > > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>
> > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>>>
> > > >
> <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>
> > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>>
> > > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>
> > <http://www.w3.org/2001/XMLSchema-instance
> <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
> > > > > <elecharny@gmail.com
> <ma...@gmail.com>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>>
> <mailto:elecharny@gmail.com <ma...@gmail.com>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>>>
> > > <mailto:elecharny@gmail.com
> <ma...@gmail.com> <mailto:elecharny@gmail.com
> <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>>
> > > > <mailto:elecharny@gmail.com
> <ma...@gmail.com>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>>
> <mailto:elecharny@gmail.com <ma...@gmail.com>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>>>
> > > <mailto:elecharny@gmail.com
> <ma...@gmail.com> <mailto:elecharny@gmail.com
> <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>>>>:
> > > > >
> > > > > 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>> <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>>> <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>> <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>>>> <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>> <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>>> <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>> <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>>>>> <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>> <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>>> <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>> <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>>>> <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>> <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>>> <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>> <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
> > > > > elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org
> <ma...@apache.org>> <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org <ma...@apache.org>>>
> > > <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org
> <ma...@apache.org>> <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org <ma...@apache.org>>>>
> > > > <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org <ma...@apache.org>>
> > > <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org
> <ma...@apache.org>>> <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org <ma...@apache.org>>
> > > <mailto:elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>>>>
> > > > >
> > > >
> > > > --
> > > > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > > > elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>
> > <mailto:elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>>
> > > <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org
> <ma...@apache.org>> <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org <ma...@apache.org>>>>
> > > >
> > >
> > > --
> > > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > > elecharny@apache.org <ma...@apache.org>
> <mailto:elecharny@apache.org <ma...@apache.org>>
> > <mailto:elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>>
> > >
> >
> >
> > --
> > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > elecharny@apache.org <ma...@apache.org>
> <mailto:elecharny@apache.org <ma...@apache.org>>
> >
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecharny@apache.org <ma...@apache.org>
>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecharny@apache.org
Re: Serialization of equality filters broken?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Ok so some more info:
The memberOf attribute is a bit special. It's first a AcriveDirectory
Attribute and its syntax is Distinguish Name Syntax. Which means it's
not purely a String, which is the reason it's base64 encoded.
Whe it comes to encode values, the following rule should apply:
"When creating DSML messages, all Attributes whose value is Java byte
array are Base64 encoded to String before being written in the DSML message.
If when creating a DSML message an Attribute is passed whose value's
type is neither String nor Java byte array, the value is converted to
String by calling the object's "toString()" method and this String value
is written in the DSML message.
"
(that is from IBM).
OASIS is a bit more light when it comes to tell what should be base64
encoded or not:
"The definition of DsmlValue permits the following types: UTF-8,
base64Binary, and any URI."
Now, to be able to know what would be the value type, there is some
attribute that needs to be added:
xsi:type="xsd:base64Binary"
Like in :
<control type="1.2.840.113556.1.4.612" criticality="true">
<controlValue xsi:type="xsd:base64Binary">
U2VhcmNoIFJlcXVlc3QgRXhhbXBsZQ==
</controlValue>
</control>
So I guess we should avoid ommitting this attribute when base64 encoding
a value.
On 08/02/2024 18:11, Emmanuel Lecharny wrote:
> Hi Patrick,
>
> I have to check why the value gets base64 encoded. I thought the issue
> was already properly addressed (see
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369
> <https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369>)
>
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>
>
> Le jeu. 8 févr. 2024 à 16:22, Patrick Peer <p.peer@synedra.com
> <ma...@synedra.com>> a écrit :
>
> Hi Emmanuel!
>
> I finally got around to upgrading to the newest version. The good
> news: The value for the equalityMatch is generated successfully. The
> bad news: IHE's HPD simulator [1] seems to have problems with the
> base64 encoding. It seems as if the xsi:type-Attribute is not
> recognized and/or dropped [2].
> Now, I think the request should be correct in the context of
> HPD-queries, and that the simulator is clumsy. I will hash that out
> with the folks at IHE. However, this leads me to think that other
> "real" implementations of HPDs will have problems with base64, too.
>
> I will now have to decide with my colleagues how to handle this. One
> possibility would be to generate the normal strings again. To do
> that, I could compile a modified version of the library myself
> (luckily I could get away with breaking the code for parsing
> requests, should that be an issue, as you hinted before). Still, I'd
> like to know how you think about reverting to generating strings in
> the official library again. At least for the case, when the value is
> a string to begin with, and a conversion to base64 would not be
> required.
>
> In any case, thanks for the fix :)!
>
> Cheers,
> Patrick
>
> [1] https://gazelle.ihe.net/HPDSimulator/home.seam
> <https://gazelle.ihe.net/HPDSimulator/home.seam>
> [2]
> https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572 <https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572>
>
> Am Di., 6. Feb. 2024 um 08:52 Uhr schrieb Emmanuel Lécharny
> <elecharny@gmail.com <ma...@gmail.com>>:
>
> Hi,
>
> the release has been voted. It's available. Enjoy!
>
> On 02/02/2024 12:05, Patrick Peer wrote:
> > Thank you very much! Much appreciated :).
> >
> > Am Fr., 2. Feb. 2024 um 10:41 Uhr schrieb Emmanuel Lécharny
> > <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>:
> >
> > The release is being voted. I expect to be out at the
> beginning of next
> > week.
> >
> > On 29/01/2024 14:03, Patrick Peer wrote:
> > > Emmanuel,
> > >
> > > can you give me a rough estimate on when a new version
> with the
> > fixes
> > > will be available? I need to upgrade due to CVEs for
> dependencies of
> > > older versions of org.apache.directory.api:api-all,
> for the
> > release of
> > > our own software. Thus I need to know whether I can
> wait for your
> > > release, or need to compile the library myself.
> > >
> > > Cheers,
> > > Patrick
> > >
> > > Am Mi., 6. Dez. 2023 um 09:26 Uhr schrieb Patrick Peer
> > > <p.peer@synedra.com <ma...@synedra.com>
> <mailto:p.peer@synedra.com <ma...@synedra.com>>
> > <mailto:p.peer@synedra.com <ma...@synedra.com>
> <mailto:p.peer@synedra.com <ma...@synedra.com>>>>:
> > >
> > > Hi Emmanuel!
> > >
> > > > Side note: I'd be interested to know what is
> your usage of the
> > > LDAP API
> > > > and why you picked it against other libs. Just
> for my
> > personnal
> > > interest!
> > > I inherited the code using the LDAP API, so my
> best guess is:
> > When
> > > Apache provides a library for the thing you want
> to do, you
> > use it :).
> > > As for the actual use case, we want to query
> Healthcare Provider
> > > Directories (HPDs) [1].
> > >
> > > > Btw, I now realize that the output is
> incorrect, even after my
> > > fix. The
> > > > produced DSML should still contain the Base64
> value, which is
> > > currently
> > > > not. I'll fix that.
> > > Given that this was a bug, and the filter values
> will be
> > generated
> > > again, setFilter(String) _should_ work after the fix.
> > However, given
> > > my experience in the field, I fear there will be
> problems
> > with HPDs
> > > that are not prepared to handle base64 values. I
> might be
> > wrong on
> > > that though, and as long as IHE's HPD simulator is
> happy, I
> > think I
> > > will use the simpler (for me) base64 filters. On
> that note,
> > do you
> > > have an estimate on when a new version will be
> released?
> > >
> > > Cheers,
> > > Patrick
> > >
> > >
> > >
> > > [1]
> > >
> >
> https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>> - 3.58 Provider Information Query
> > >
> > > Am Di., 5. Dez. 2023 um 23:02 Uhr schrieb Emmanuel
> Lécharny
> > > <elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>>:
> > >
> > > 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
> <http://www.w3.org/2001/XMLSchema>
> > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>>
> > > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>
> > <http://www.w3.org/2001/XMLSchema
> <http://www.w3.org/2001/XMLSchema>>>"
> > >
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>
> > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>>
> > > <http://www.w3.org/2001/XMLSchema-instance
> <http://www.w3.org/2001/XMLSchema-instance>
> > <http://www.w3.org/2001/XMLSchema-instance
> <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
> > > > <elecharny@gmail.com
> <ma...@gmail.com> <mailto:elecharny@gmail.com
> <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>
> > > <mailto:elecharny@gmail.com
> <ma...@gmail.com> <mailto:elecharny@gmail.com
> <ma...@gmail.com>>
> > <mailto:elecharny@gmail.com <ma...@gmail.com>
> <mailto:elecharny@gmail.com <ma...@gmail.com>>>>>:
> > > >
> > > > 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>> <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>>> <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>> <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>>>> <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>> <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>>> <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>> <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
> > > > elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>
> > <mailto:elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>>
> > > <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org
> <ma...@apache.org>> <mailto:elecharny@apache.org
> <ma...@apache.org>
> > <mailto:elecharny@apache.org <ma...@apache.org>>>>
> > > >
> > >
> > > --
> > > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > > elecharny@apache.org <ma...@apache.org>
> <mailto:elecharny@apache.org <ma...@apache.org>>
> > <mailto:elecharny@apache.org
> <ma...@apache.org> <mailto:elecharny@apache.org
> <ma...@apache.org>>>
> > >
> >
> > --
> > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > elecharny@apache.org <ma...@apache.org>
> <mailto:elecharny@apache.org <ma...@apache.org>>
> >
>
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecharny@apache.org <ma...@apache.org>
>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecharny@apache.org
Re: Serialization of equality filters broken?
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi Patrick,
I have to check why the value gets base64 encoded. I thought the issue was
already properly addressed (see
https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369)
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Le jeu. 8 févr. 2024 à 16:22, Patrick Peer <p....@synedra.com> a écrit :
> Hi Emmanuel!
>
> I finally got around to upgrading to the newest version. The good news:
> The value for the equalityMatch is generated successfully. The bad news:
> IHE's HPD simulator [1] seems to have problems with the base64 encoding. It
> seems as if the xsi:type-Attribute is not recognized and/or dropped [2].
> Now, I think the request should be correct in the context of HPD-queries,
> and that the simulator is clumsy. I will hash that out with the folks at
> IHE. However, this leads me to think that other "real" implementations of
> HPDs will have problems with base64, too.
>
> I will now have to decide with my colleagues how to handle this. One
> possibility would be to generate the normal strings again. To do that, I
> could compile a modified version of the library myself (luckily I could get
> away with breaking the code for parsing requests, should that be an
> issue, as you hinted before). Still, I'd like to know how you think about
> reverting to generating strings in the official library again. At least for
> the case, when the value is a string to begin with, and a conversion to
> base64 would not be required.
>
> In any case, thanks for the fix :)!
>
> Cheers,
> Patrick
>
> [1] https://gazelle.ihe.net/HPDSimulator/home.seam
> [2]
> https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572
>
> Am Di., 6. Feb. 2024 um 08:52 Uhr schrieb Emmanuel Lécharny <
> elecharny@gmail.com>:
>
>> Hi,
>>
>> the release has been voted. It's available. Enjoy!
>>
>> On 02/02/2024 12:05, Patrick Peer wrote:
>> > Thank you very much! Much appreciated :).
>> >
>> > Am Fr., 2. Feb. 2024 um 10:41 Uhr schrieb Emmanuel Lécharny
>> > <elecharny@gmail.com <ma...@gmail.com>>:
>> >
>> > The release is being voted. I expect to be out at the beginning of
>> next
>> > week.
>> >
>> > On 29/01/2024 14:03, Patrick Peer wrote:
>> > > Emmanuel,
>> > >
>> > > can you give me a rough estimate on when a new version with the
>> > fixes
>> > > will be available? I need to upgrade due to CVEs for
>> dependencies of
>> > > older versions of org.apache.directory.api:api-all, for the
>> > release of
>> > > our own software. Thus I need to know whether I can wait for your
>> > > release, or need to compile the library myself.
>> > >
>> > > Cheers,
>> > > Patrick
>> > >
>> > > Am Mi., 6. Dez. 2023 um 09:26 Uhr schrieb Patrick Peer
>> > > <p.peer@synedra.com <ma...@synedra.com>
>> > <mailto:p.peer@synedra.com <ma...@synedra.com>>>:
>> > >
>> > > Hi Emmanuel!
>> > >
>> > > > Side note: I'd be interested to know what is your usage
>> of the
>> > > LDAP API
>> > > > and why you picked it against other libs. Just for my
>> > personnal
>> > > interest!
>> > > I inherited the code using the LDAP API, so my best guess is:
>> > When
>> > > Apache provides a library for the thing you want to do, you
>> > use it :).
>> > > As for the actual use case, we want to query Healthcare
>> Provider
>> > > Directories (HPDs) [1].
>> > >
>> > > > Btw, I now realize that the output is incorrect, even
>> after my
>> > > fix. The
>> > > > produced DSML should still contain the Base64 value,
>> which is
>> > > currently
>> > > > not. I'll fix that.
>> > > Given that this was a bug, and the filter values will be
>> > generated
>> > > again, setFilter(String) _should_ work after the fix.
>> > However, given
>> > > my experience in the field, I fear there will be problems
>> > with HPDs
>> > > that are not prepared to handle base64 values. I might be
>> > wrong on
>> > > that though, and as long as IHE's HPD simulator is happy, I
>> > think I
>> > > will use the simpler (for me) base64 filters. On that note,
>> > do you
>> > > have an estimate on when a new version will be released?
>> > >
>> > > Cheers,
>> > > Patrick
>> > >
>> > >
>> > >
>> > > [1]
>> > >
>> >
>> https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <
>> https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf> <
>> https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <
>> https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>
>> - 3.58 Provider Information Query
>> > >
>> > > Am Di., 5. Dez. 2023 um 23:02 Uhr schrieb Emmanuel Lécharny
>> > > <elecharny@gmail.com <ma...@gmail.com>
>> > <mailto:elecharny@gmail.com <ma...@gmail.com>>>:
>> > >
>> > > 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
>> > <http://www.w3.org/2001/XMLSchema>
>> > > <http://www.w3.org/2001/XMLSchema
>> > <http://www.w3.org/2001/XMLSchema>>"
>> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
>> > <http://www.w3.org/2001/XMLSchema-instance>
>> > > <http://www.w3.org/2001/XMLSchema-instance
>> > <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
>> > > > <elecharny@gmail.com <ma...@gmail.com>
>> > <mailto:elecharny@gmail.com <ma...@gmail.com>>
>> > > <mailto:elecharny@gmail.com <ma...@gmail.com>
>> > <mailto:elecharny@gmail.com <ma...@gmail.com>>>>:
>> > > >
>> > > > 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>>
>> <
>> 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>>>
>> <
>> 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>>
>> <
>> 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
>> > > > elecharny@apache.org <ma...@apache.org>
>> > <mailto:elecharny@apache.org <ma...@apache.org>>
>> > > <mailto:elecharny@apache.org
>> > <ma...@apache.org> <mailto:elecharny@apache.org
>> > <ma...@apache.org>>>
>> > > >
>> > >
>> > > --
>> > > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
>> > > elecharny@apache.org <ma...@apache.org>
>> > <mailto:elecharny@apache.org <ma...@apache.org>>
>> > >
>> >
>> > --
>> > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
>> > elecharny@apache.org <ma...@apache.org>
>> >
>>
>
>> --
>> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
>> elecharny@apache.org
>>
>
Re: Serialization of equality filters broken?
Posted by Patrick Peer <p....@synedra.com>.
Emmanuel,
can you give me a rough estimate on when a new version with the fixes will
be available? I need to upgrade due to CVEs for dependencies of older
versions of org.apache.directory.api:api-all, for the release of our own
software. Thus I need to know whether I can wait for your release, or need
to compile the library myself.
Cheers,
Patrick
Am Mi., 6. Dez. 2023 um 09:26 Uhr schrieb Patrick Peer <p....@synedra.com>:
> Hi Emmanuel!
>
> > Side note: I'd be interested to know what is your usage of the LDAP API
> > and why you picked it against other libs. Just for my personnal interest!
> I inherited the code using the LDAP API, so my best guess is: When Apache
> provides a library for the thing you want to do, you use it :).
> As for the actual use case, we want to query Healthcare Provider
> Directories (HPDs) [1].
>
> > Btw, I now realize that the output is incorrect, even after my fix. The
> > produced DSML should still contain the Base64 value, which is currently
> > not. I'll fix that.
> Given that this was a bug, and the filter values will be generated again,
> setFilter(String) _should_ work after the fix. However, given my experience
> in the field, I fear there will be problems with HPDs that are not prepared
> to handle base64 values. I might be wrong on that though, and as long as
> IHE's HPD simulator is happy, I think I will use the simpler (for me)
> base64 filters. On that note, do you have an estimate on when a new version
> will be released?
>
> Cheers,
> Patrick
>
>
>
> [1] https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf
> - 3.58 Provider Information Query
>
> Am Di., 5. Dez. 2023 um 23:02 Uhr schrieb Emmanuel Lécharny <
> elecharny@gmail.com>:
>
>> 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
>> > <elecharny@gmail.com <ma...@gmail.com>>:
>> >
>> > 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
>> > elecharny@apache.org <ma...@apache.org>
>> >
>>
>> --
>> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
>> elecharny@apache.org
>>
>
Re: Serialization of equality filters broken?
Posted by Patrick Peer <p....@synedra.com>.
Hi Emmanuel!
> Side note: I'd be interested to know what is your usage of the LDAP API
> and why you picked it against other libs. Just for my personnal interest!
I inherited the code using the LDAP API, so my best guess is: When Apache
provides a library for the thing you want to do, you use it :).
As for the actual use case, we want to query Healthcare Provider
Directories (HPDs) [1].
> Btw, I now realize that the output is incorrect, even after my fix. The
> produced DSML should still contain the Base64 value, which is currently
> not. I'll fix that.
Given that this was a bug, and the filter values will be generated again,
setFilter(String) _should_ work after the fix. However, given my experience
in the field, I fear there will be problems with HPDs that are not prepared
to handle base64 values. I might be wrong on that though, and as long as
IHE's HPD simulator is happy, I think I will use the simpler (for me)
base64 filters. On that note, do you have an estimate on when a new version
will be released?
Cheers,
Patrick
[1] https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf
- 3.58 Provider Information Query
Am Di., 5. Dez. 2023 um 23:02 Uhr schrieb Emmanuel Lécharny <
elecharny@gmail.com>:
> 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
> > <elecharny@gmail.com <ma...@gmail.com>>:
> >
> > 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
> > elecharny@apache.org <ma...@apache.org>
> >
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecharny@apache.org
>
Re: Serialization of equality filters broken?
Posted by Emmanuel Lécharny <el...@gmail.com>.
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
> <elecharny@gmail.com <ma...@gmail.com>>:
>
> 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
> elecharny@apache.org <ma...@apache.org>
>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecharny@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Serialization of equality filters broken?
Posted by Patrick Peer <p....@synedra.com>.
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 <
elecharny@gmail.com>:
> 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
> >
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> elecharny@apache.org
>
Re: Serialization of equality filters broken?
Posted by Emmanuel Lécharny <el...@gmail.com>.
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>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecharny@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Serialization of equality filters broken?
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi!
long story short: we have added some more check that break your code...
More detailed answer:
* when you inject some filter in your request, we parse it and try as
much as possible to detect which AttributeType is to be associated with
each attribute.
* Those AttributeTypes contain information about the type of attribute
(is it Human Readable (HR) or not).
* To do that, we need a SchemaManager which needs to be initialized at
some point
* Then we need to inject a parsed filter into the DsmlSearchRequest.
The code then looks like that:
SearchRequestDsml searchRequest = new
SearchRequestDsml(LdapApiServiceFactory.getSingleton());
SchemaManager schemaManager = new DefaultSchemaManager();
ExprNode filter = FilterParser.parse( schemaManager,
"(uid=SomeArbitraryBenignString)" );
searchRequest.setFilter( filter );
and now, the filter knows that uid is HR...
Ultra complex :/
There is no silmple way to get that fixed, because it's not simple to
propagate the schemaManager into all the DSML classes. Ideally speaking,
we should expose some method like:
searchRequest.setFilter( schemaManager, `
"(uid=SomeArbitraryBenignString)" );
to make the LDAP API life easier.
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>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecharny@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org