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