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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>:
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
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>:
>
> 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
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>:
> >
> > 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
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>:
> >
> > 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
> > > <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>>:
> > >
> > > Hi again!
> > >
> > > I have modified the LDAP API to be able
to deal
> with the
> > attributeType
> > > properly when we have a SchemaManager,
and to do
> so in a
> > more user
> > > friendly way.
> > >
> > > Here is thge modified original test:
> > >
> > > @Test
> > > public void
testMinimalEqualityRequest() throws
> > Exception {
> > > SearchRequestDsml
searchRequest = new
> > >
> SearchRequestDsml(LdapApiServiceFactory.getSingleton());
> > >
> > > // Create the SchemaManager
instance
> > > SchemaManager schemaManager = new
> > DefaultSchemaManager();
> > >
> > > // Use it as a parameter so
that the
> filter get
> > properly parsed
> > > searchRequest.setFilter(
schemaManager,
> > > "(uid=SomeArbitraryBenignString)" );
> > >
> > >
> > > BatchRequestDsml batchRequest
= new
> > BatchRequestDsml();
> > >
batchRequest.addRequest(searchRequest);
> > > String dsmlString =
batchRequest.toDsml();
> > >
> > > System.out.print( dsmlString );
> > > }
> > >
> > > which prints out the expected result:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <batchRequest>
> > > <searchRequest
derefAliases="derefAlways">
> > > <filter>
> > > <equalityMatch name="uid">
> > >
<value>SomeArbitraryBenignString</value>
> > > </equalityMatch>
> > > </filter>
> > > </searchRequest>
> > > </batchRequest>
> > >
> > > It will most certainly be included in
2.1.6.
> > >
> > >
> > > On 04/12/2023 21:18, Patrick Peer wrote:
> > > > Hello!
> > > >
> > > > I recently upgraded the version
> > > of org.apache.directory.api:api-all from
> > > > 2.1.0 to 2.1.5 in the dependencies
of our product,
> > which resulted in
> > > > some test failures on my end. As it
seems,
> values for
> > equality
> > > filters
> > > > are not set in the request anymore.
For your
> > convenience, I cobbled
> > > > together a minimal test case to
reproduce the
> > condition [1].
> > > It works
> > > > with Version 2.1.0 and does not work
with 2.1.5.
> > > >
> > > > Upon further investigation, I think
I found
> some issues
> > > >
> > >
> >
>
in org.apache.directory.api.dsmlv2.request.SearchRequestDsml.toDsml(Element, ExprNode)@2.1.5:
> > > > + On line 559 value.isHumanReadable() is
> queried to decide
> > > whether to
> > > > use the value as is, or to encode it
in base64. =>
> > This seems
> > > broken,
> > > > since, as far as I can tell,
> > > >
> >
the org.apache.directory.api.ldap.model.entry.Value.isHR
> flag is
> > > always
> > > > false at this particular point in
the code.
> > > >
> > >
> >
>
+ org.apache.directory.api.dsmlv2.ParserUtils.base64Encode(Object)
> only
> > > > yields base64 values for byte[] and
String,
> however here a
> > > >
org.apache.directory.api.ldap.model.entry.Value is
> > passed, which
> > > will
> > > > always result in an empty String.
> > > >
> > > > The corresponding commit should be [2].
> > > >
> > > > Do you agree that this is a bug, and
should I jump
> > through the
> > > hoops to
> > > > open a Jira issue, or is there an
> alternative/intended
> > way to work
> > > > around this?
> > > >
> > > > Cheers,
> > > > Patrick Peer
> > > >
> > > >
> > > >
> > > > [1]
> > > > @Test
> > > > public void
testMinimalEqualityRequest() throws
> > Exception {
> > > > SearchRequestDsml searchRequest
= new
> > > >
> SearchRequestDsml(LdapApiServiceFactory.getSingleton());
> > > >
> >
searchRequest.setFilter("(uid=SomeArbitraryBenignString)");
> > > >
> > > > BatchRequestDsml batchRequest = new
> > BatchRequestDsml();
> > > >
batchRequest.addRequest(searchRequest);
> > > > String dsmlString =
batchRequest.toDsml();
> > > >
> > > >
> >
assertThat(dsmlString).contains("SomeArbitraryBenignString");
> > > > }
> > > >
> > > > [2]
> > > >
> > >
> >
>
https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<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
> > > [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
> > >
> >
> > --
> > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> >
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
[email protected] <mailto:[email protected]>
