Re: [API] LDAP Connection Pool - releasing/closing request

> On Feb 21, 2024, at 4:21 PM, Emmanuel Lécharny wrote: > > On 21/02/2024 22:09, Brian Demers wrote: >> (Mostly thinking out loud) >> Is there any downside in us wrapping the NetworkLdapConnection returned by >> the LdapConnectionPool to call releaseConnection instead of close? > > We could

Re: Not closing search cursor

> > On Jul 13, 2022, at 9:09 PM, Maxim Solodovnik wrote: > > try (SearchCursor searchResults = search( …);) { >. > } > > :))) > On Jul 14, 2022, at 10:50 PM, Emmanuel Lécharny wrote: > > > I have updated the doco to show how to use the try-with-resource. > > Thanks ! Hey Maxim

Not closing search cursor

Hello, Recently noticed the fortress code is not closing the search cursor. Take the GroupDAO.find[1] example (listed below). Same pattern across the codebase despite clear warnings in the doc: "Don’t forget to close the cursor, otherwise the associated data remains in memory forever (causing

Re: log4j update

> On Dec 21, 2021, at 3:18 AM, Wartner , Steffen - SID-LRZS > wrote: > > my name is Steffen Wartner and I'm using the Apache Directory LDAP API for > one of my projects. There are security issues with log4j (see > https://logging.apache.org/log4j/2.x/security.html) and I wanted to ask, when

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

> On Jul 4, 2021, at 1:16 PM, Stefan Seelmann wrote: > > Oh sorry, my question regarding ApacheDS didn't make sense because in > ApacheDS only TLSv1.2 is enabled so the negotiation chose 1.2 event if > 1.3 is enabled in the API. No worries. I needed to test LDAPS on ApacheDS anyway as it has

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

> On Jul 4, 2021, at 9:12 AM, Shawn McKinney wrote: > > I don’t think it’s server dependent as I’ve noticed the TLS connection and > binds are successful with OpenLDAP before the timeout in the API. > Should know by now not to ‘think’ and just test. Don’t know how many t

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

> On Jul 4, 2021, at 9:12 AM, Shawn McKinney wrote: > > I don’t think it’s server dependent as I’ve noticed the TLS connection and > binds are successful with OpenLDAP before the timeout in the API. Stefan, I’ve got 2.0.6 running on a linode VM along with OpenLDAP using LDAPS.

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

> On Jul 4, 2021, at 8:08 AM, Stefan Seelmann wrote: > > On 7/3/21 7:26 PM, Shawn McKinney wrote: >> That is when TLSv1.3 was added as a default enabled protocol in the API, >> fortress started having LDAPS connections problems. >> >> Specifically,

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

> On Jul 3, 2021, at 2:10 PM, Stefan Seelmann wrote: > > I added TLSv1.3 to the default protocols in [1]. There is an open issue > for Mina [2] that describes timeouts when using v1.3, please see my > comment there. When used in Studio I didn't encounter any issue in tests > against OpenLDAP

[REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

Hello, A problem with Fortress using LDAPS in the API. It was brought on by this commit: https://github.com/apache/directory-ldap-api/commit/4322886f8ed9fe0d2c588f0c557e92e4d160149f ``` public class LdapNetworkConnection … // Default to TLS sslFilter.setEnabledProtocols( new

Re: Migration to 2.0 API - RBAC Accelerator Extended Operations

> On Jun 24, 2021, at 8:43 PM, Emmanuel Lécharny wrote: > > On 24/06/2021 20:38, Shawn McKinney wrote: >> Moving onto the last hurdle for 2.0 migration… >> To get the accelerator client talking with OpenLDAP RBAC overlay, for >> extended operations. >> Em

Re: [RESOLVED] Migration to 2.0 API has moved onto something a bit more relaxing

> On Jun 24, 2021, at 2:15 PM, Stefan Seelmann wrote: > > Looks good. The OSGi import/export definitions were missing, I added > them. They are required by Studio because it's based on Eclipse. > > https://github.com/apache/directory-ldap-api/commit/7406985321280d745cc2baf0ef017e9108ce3dfb >

[RESOLVED] Re: Migration to 2.0 API has moved onto something a bit more relaxing

Changes pushed into api for the new control: https://github.com/apache/directory-ldap-api/commit/12353c1487412b0c7e0d36a68297ab713dd0 Let me know if there’s anything I missed / got wrong. I’ve left the control in fortress for now, until the 2.0.3 release is out. That resolves this issue,

[RESOLVED] Re: Migrate to 2.0 API - Help w/ PW Policy Control

> On Jun 23, 2021, at 11:26 PM, Emmanuel Lécharny wrote: > > > On 23/06/2021 17:32, Shawn McKinney wrote: >> Next up on migration tasks, howto process password policy control returned >> from the server. >> The 1.x way >> [UserDAO](https://github.com

Re: Migration to 2.0 API has moved onto something a bit more relaxing

Relaxed ;-) — Shawn > On Jun 23, 2021, at 3:04 PM, Shawn McKinney wrote: > > Onto the next problem… > > As described back in April on this ML: > > [Relax Control and password > policies](http://mail-archives.apache.org/mod_mbox/directory-api/202104.mbox/%3CECC48E64-6CF

Migration to 2.0 API has moved onto something a bit more relaxing

Onto the next problem… As described back in April on this ML: [Relax Control and password policies](http://mail-archives.apache.org/mod_mbox/directory-api/202104.mbox/%3CECC48E64-6CF9-40B7-8BC4-FCE60E40684E%40apache.org%3E) I added support to use the Relax Control to the fortress core code

[Solved] Re: Migrate to 2.0 API - Help w/ PW Policy Control

() > 0 ){ … } if ( respCtrl.getGraceAuthNRemaining() > 0 ){ … } ``` — Shawn > On Jun 23, 2021, at 10:32 AM, Shawn McKinney wrote: > > Next up on migration tasks, howto process password policy control returned > from the server. > > The 1.x way > [UserDAO](https://

Re: Migrate to 2.0 API

> On Jun 22, 2021, at 2:01 PM, Stefan Seelmann wrote: > > On 6/22/21 3:47 PM, Shawn McKinney wrote: >> I switched from this://PoolableObjectFactory >> poolFactory = new ValidatingPoolableLdapConnectionFactory( config ); >> >> To: >>

Migrate to 2.0 API

Hello, I am finally taking on the task of migrating the Fortress Core to use Apache LDAP API! So, I have found this: https://directory.apache.org/api/migration-guide.html Which did help me get started. Actually, the code compiles (in this branch):

Relax Control and password policies

Due to changes that are now in the OpenLDAP mainline and part of their 2.5 beta release, password policies work a bit differently. First, the schema ppolicy.schema is built in and isn’t included as entry in the slapd config. This change doesn’t have relevance here as it’s an implementation

Re: LdapNetworkConnection. add eating exceptions

t;> the response from the server is processed by >> ResultCodeEnum.processResponse() which throws LDAP specific exceptions >> for non-successfule responses. >> If you use the raw request/response methods you can use that utility >> method too if you like. >> I agree

Re: LdapNetworkConnection. add eating exceptions

> On Apr 5, 2021, at 2:32 PM, Stefan Seelmann wrote: > > I can only speak for API V2 but I think for V1 it's similar. > > I also was surprised by that behavior, but it's "as designed" and makes > sense and is consistent :) > > The LdapConnection methods that take a raw XyzRequest object

LdapNetworkConnection. add eating exceptions

Hello, Stumbled on this today. The error occurs adding entry to directory and constraint violation occurs. The error is expected as I’m manipulating an pw policy attribute that is DSA controlled. I’ve changed the code on adds to be able to forward the DSA control: ``` AddRequest

Re: LdapConnectionPool.getConnection doing extraneous search?

> On Mar 23, 2021, at 3:00 AM, Emmanuel Lécharny wrote: > > > On 22/03/2021 19:41, Shawn McKinney wrote: >>> On Mar 22, 2021, at 11:05 AM, Emmanuel Lécharny wrote: >>> >>> LDAP connections are quite stable. Again, this check is there to res

Re: LdapConnectionPool.getConnection doing extraneous search?

> On Mar 22, 2021, at 2:21 PM, Stefan Seelmann wrote: > > Would a Java Dynamic Proxy help? > > It would implement the LdapConnection interface. > > When a method is invoked it borrows a connection from the pool (without > testing it), executes the method, returns the connection to the pool,

Re: LdapConnectionPool.getConnection doing extraneous search?

> On Mar 22, 2021, at 11:05 AM, Emmanuel Lécharny wrote: > > LDAP connections are quite stable. Again, this check is there to respect the > commons-pool API contract. If the connection is dead, then doing this check > will let the pool fetching another connection, which is good. OTOH, if you

Re: LdapConnectionPool.getConnection doing extraneous search?

> On Mar 22, 2021, at 10:43 AM, Shawn McKinney wrote: > >> >> The risk not doing such a check is very very tenuous. > Sorry, but asking for a clarification here. Do you mean, not doing the check is risky? Or, is OK. > This is what I was hoping you were go

Re: LdapConnectionPool.getConnection doing extraneous search?

> On Mar 20, 2021, at 10:40 PM, Emmanuel Lécharny wrote: > > I guess that the very first time we create the connection, when asking for > one from a pool, we test it beforehandd, and this is done with the less > costly operation: a dummy search. > > This is due to commons-pool logic where

LdapConnectionPool.getConnection doing extraneous search?

Hello, I’m using LDAP API v1.0.3 inside fortress. My question is when retrieving connections from the pool using this: ``` public LdapConnection getConnection() Gives a LdapConnection fetched from the pool. Returns: an LdapConnection object from pool ``` I noticed in the OpenLDAP logs

Re: Toward a 2.0 GA

> On Jan 16, 2019, at 3:54 PM, Emmanuel Lécharny wrote: > > The Server, when started, will try to load the Keystore content: > > o If there is no provided KeyStore file, the server will use create its own > Keystore, based on the default SUN provider. > o Otherwise, the server will try to

Re: SASL/EXTERNAL binding

> On Nov 16, 2017, at 2:35 PM, Emmanuel Lécharny wrote: > > Regarding this specific feature, teh real problem for us was to get it > tested. But if you don't mind doing this part of the job, we probably > can move forward ! +1 to needing help with the testing. I’ve never

Re: Ldap API Custom Controls

> On Sep 7, 2017, at 8:41 PM, CRAIG BENNER wrote: > > It will take some changes to get a wireshark capture, since Password's can > only be managed over a secure connection. Hopefully tomorrow I can get you > the wireshark capture Wonder if it would be easier to just

Re: LDAP API 1.0 status

> On Jan 23, 2017, at 3:23 AM, Emmanuel Lécharny wrote: > > Some effort has been put on teh API documentation - thanks to Shawn for > the proof reading - but there is stilla lot to do. I'm currently > working on the Security pages >

Re: cURRENT uSER gUID XTATUS

Started wiki page: https://en.wikipedia.org/wiki/Apache_ldap_api (needs a little love) Shawn > On Jan 1, 2017, at 12:07 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > > > > Le 01/01/2017 à 16:31, Shawn McKinney a écrit : >>> On Jan 1, 2017, at 5:04

Re: LDAP API 1.0-GA preparation

> On Dec 18, 2016, at 11:54 AM, Emmanuel Lécharny wrote: > > Obviously, there is a lot of thing to add... I think the structure might > also be improved. Anyway, we have something to start with... > > If you feel like to start reviewing the completed pages, please do so !

Re: API changes impact on ApacheDS, take 6

> On May 29, 2016, at 6:47 PM, Emmanuel Lécharny wrote: > > Sadly, the week-end is over, and I'll have to go back to work tomorrow. > I hope to be able to fix the remaining errors in the next coming evenings. Yes I understand your affliction all too well. You clearly have

Re: Value classes refactoring

> On Mar 23, 2016, at 6:44 PM, Emmanuel Lécharny wrote: > > > This is a work in progress, but I'm confident that would bring us to a > better and more stable API. I don’t pretend to know about all of the details but it makes sense at a high level and I appreciate your