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 <[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 > [2] > 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]>: > >> 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]>>: >> > >> > 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]>>>: >> > > >> > > 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 >> > > <[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>>" >> > > 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 >> > > > <[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 >> >>>> >> > > > >> > > > -- >> > > > *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]> >> > >> > >> -- >> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 >> [email protected] >> >
