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

[Shawn McKinney]

> 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 do that, to some extent. LdapNetworkConnection can be extended, so 
> we could add the Closeable interface to it, overriding the close() method and 
> adding something like a shutdown() method that would call the parent's 
> close() method:
> 
> public class PooledLdapNetworkConnection extends LdapNetworkConnection 
> implements AutoCloseable
> {
>   LdapConnectionPool pool;
>   LdapConnection kdapConnection;
>   
>   public PooledLdapNetworkConnection( LdapConnection ldapConnection, 
> LdapConnectionPool pool )
>   {
>   this.ldapConnection = ldapConnection;
>   this.pool = pool;
>   }
>   
>   @Override   
>   public void close()
>   {
>   try
>   {
>   pool.releaseConnection( ldapConnection );
>   }
>   catch ( LdapException le )
>   {
>   // Nothing to do here
>   }
>   }
>   
>   public void shutdown()
>   {
>   ldapConnection.close();
>   }
> }
> 
> The problem here is that the connection is never associated to the pool 
> unless you can have it pushed into the pool, which is normally done by the 
> factory and specifically the makeObject() method;
> 
> Here we have an issue:
> - we want to be able to get a connection from the pool, which extends 
> Closeable
> - such an object is created by the factory which does create 
> LdapNetworkConnection instances.
> 
> So we should  create a new LdapConnectionFactory that does instanciate 
> PooledLdapNetworkConnection instances in its newLdapConnection() function, 
> which get called by the factory.
> 
> There is some plumbing to be done, and it will certainly not be 
> straightforward, but still.
> 
> Even simpler, we could decide that the factory only creates pooleable 
> instances (because all in all, this is the only reason we have such a 
> factory).
> 

Chiming in here with another option:

Fortress uses Apache Commons pooling mechanism. It doesn’t allow 
try-with-resources (actually maybe that can be done), instead we use 
try-catch-finally.

Proven, stable, tested in all sorts of conditions.

Here’s our wrapper that manages three kinds of connections:

https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/ldap/LdapConnectionProvider.java
 

You certainly wouldn’t need all of the stuff we have here.

—
Shawn

> 
> 
>> On Wed, Feb 21, 2024 at 12:57 PM Emmanuel Lécharny 
>> wrote:
>>> Hi Brian,
>>> 
>>> long story short: the LdapConnection interface (and implementation)
>>> already has a close() method that shutdowns the IO connection, so it's
>>> not possible to use the try-with-resources feature, because that would
>>> have meant changing the LDAP API to make the close() method actually
>>> close the LDAP session, not the IO connection...
>>> 
>>> So we added the releaseConnection() method which puts back the
>>> connection into the pool, but needs to be called explicitly.
>>> 
>>> yes, it's a bit of a burden...
>>> 
>>> Keep in mind that the LDAP API has been defined in 2006, 8 years before
>>> try-with-resources was included in Java 8 :/
>>> 
>>> 
>>> On 21/02/2024 17:59, Brian Demers wrote:
 I'm hacking away on a SCIMple + ApacheDS + LDAP API example.
 I haven't used the LDAP API project before, but the docs have been a big
 help!
 
 One thing I'm struggling with is the way connection pooling _should_ be
 used.
 
 For example, a non-pooled request could be created doing something like
 this:
 
 ```
 try (LdapConnection connection = new LdapNetworkConnection( "localhost",
 389 )) {
// do something with connection
 }
 ```
 
 The connection will close and everyone is fine.
 
 When using a connection pool the pattern is a little different
 
 I was doing something like this:
 
 ```
 try (LdapConnection connection = connectionPool.getConnection()) {
// do something with connection
 }
 ```
 
 But after making that change, I started seeing tests hang, after a few of
 them had run and used a connection (possibly connections were locked)
 
 I stumbled on one of the connection pooling tests that looked like I
>>> should
 be calling `connectionPool.releaseConnection(connection)`
 That seemed to fix my issue (this should be mentioned here,
 
>>> https://directory.apache.org/api/user-guide/2.1-connection-disconnection.html
>>> ,
 I submit a doc fix once this thread is resolved)
 
 So that ends up being something like this
 ```
 

Re: Not closing search cursor

[Shawn McKinney]

> 
> 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 and Emmanuel, 

I’ll shoehorn it in with the existing connection resource, that also has to be 
closed.  Currently it uses the finally block, which isn’t a good thing (either).

Using the w/ resource way is definitely the way to go.

Thanks for the help.

—
Shawn 

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Not closing search cursor

[Shawn McKinney]

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 a memory leak)! Best practice is to use 
try-with-resources statement.” [2]

Obviously, we don’t want to be leaking.  What’s the recommendation here, should 
I change the code?


GroupDAO.find

```java
List find( Group group ) throws FinderException
{
...
SearchCursor searchResults;
try
{
...
searchResults = search( …);

while ( searchResults.next() )
{
groupList.add( unloadLdapEntry( searchResults.getEntry(), sequence++ ) );
}

…

catch ( CursorException e )
{
  // no cursor close here
}
catch ( LdapException e )
{
  // or here
}
finally
{
 closeAdminConnection( ld );
 // and worse? Not here either
}

return groupList;
}
``` 

—
Shawn

[1](https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/impl/GroupDAO.java)

[2](https://directory.apache.org/api/user-guide/2.3-searching.html)


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: log4j update

[Shawn McKinney]

> 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 
> the log4j Version 1.2.17 will be updated to 2.17.0 ?

Hello Steffen,

The LDAP API uses Log4j 1.2x which is not affected by the Log4Shell 
(CVE-2021-44228).

Thanks

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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 been a while 
since I’ve last tried.  Found and solved a glitch or two so it was time well 
spent.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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 times 
I’ve been burned by assumptions.  :/

> 
> But, testing latest w/ LDAPS and ApacheDS is on my list of todos.


After enabling LDAPS on ApacheDS, connections with TLSv3 allowed as an enabled 
protocol work fine.

So, for some reason OpenLDAP and the LDAP API’s TLS 1.3 as an enabled protocol 
don’t get along.

—
Shawn



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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.

I can make this available to you if you want to have a look.  

Send me your public SSH key and I’ll add you, provide the info on where stuff 
is.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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, connections hang during bind ops, as they’re retrieved from 
>> the pool.
>> 
>> Looking at the server log, the bind was successful, but the API's async 
>> handler (ignores?) times out.
> 
> Can you please explain the steps to reproduce this issue? Does it happen
> when running the Fortress integration tests? Or the load tests? And only
> when testing against OpenDLAP or also when testing against ApacheDS?

Anytime LDAPS is enabled it happens.  Oddly, sometimes it'll successfully 
connects on the first operation, but usually not. Regardless, timeouts always 
happen on all subsequent binds.

So, yes happens during integration tests with OpenLDAP.  Or, when trying to run 
a load:

https://github.com/apache/directory-fortress-core#section-10-instructions-to-load-policy-data-using-apache-fortress-load-utility

Or, the console:

https://github.com/apache/directory-fortress-core#section-12-instructions-to-run-the-apache-fortress-command-console

I’ve tested the latest with ApacheDS, but not with LDAPS - yet.

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.

But, testing latest w/ LDAPS and ApacheDS is on my list of todos.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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 or 389ds, only when using it in ApacheDS, so I assumed
> it's only a server-side problem. But your observations proves that my
> assumption was wrong.
> 
> Which Java version are you using? I ask because I only tested with Java
> 11 and 17-ea, but not with Java 8.
> 

Hi Stefan,

Problem first observed on a Centos8 VM:
Java version: 1.8.0_292, vendor: Red Hat, Inc., runtime: 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.292.b10-1.el8_4.x86_64/jre

But, later, also on my dev workstation:
Java version: 11.0.11, vendor: Ubuntu, runtime: 
/usr/lib/jvm/java-11-openjdk-amd64

> Otherwise I think you aren't doing anything wrong. Either continue with
> your workaround, or we need to revert that change in the LDAP API until
> the problem is fixed in Mina.

OK, cool, not going to worry about it then.

I’ll parameterize the supported TLS protocols (in fortress) providing a default 
that leaves out TLSv1.3 for this release. 

Users can supply their own list of protocols, in the properties file, making 
1.3 possible.

Appreciate the quick response.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

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 String[]
- { "TLSv1", "TLSv1.1", "TLSv1.2" } );
+ { "TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3" } );
```

That is when TLSv1.3 was added as a default enabled protocol in the API, 
fortress started having LDAPS connections problems.

Specifically, connections hang during bind ops, as they’re retrieved from the 
pool.

Looking at the server log, the bind was successful, but the API's async handler 
(ignores?) times out.

When I add this to the Fortress connection pool initialization:

```
config.setEnabledProtocols( new String[] { "TLSv1", "TLSv1.1", "TLSv1.2" } );
```

Everything then works again as it should.  In other words, when bypassing 
TLSv1.3 on the client side, it works again.

Not sure what’s going on, or if my workaround is the best way to handle this 
situation.

Any ideas on what I'm doing wrong?

Thanks,

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migration to 2.0 API - RBAC Accelerator Extended Operations

[Shawn McKinney]

> 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.
>> Emmanuel, as I recall some time ago that the RBAC accelerator client would 
>> need to be reworked when we moved to 2.0.
>> Do you recall what the issue was?
> 
> The ASN.1 encoding has been rewritten from scratch. The idea was to use a 
> preallocated buffer, which get filled from the end, instead of computing the 
> result size, allocate the buffer and fill it.
> 
> It saves the length computation cost most of the time (if the buffer gets too 
> small, we reallocate it)

OK

> 
>> As it stands, I’m getting server side assertion failure.  Before I jump to 
>> far into this wanted to check with you.
>> If you want to look at the server side log, it’s here:
>> https://issues.apache.org/jira/browse/FC-238?focusedCommentId=17369035=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17369035
> 
> The logs aren't helful, there is not enough data in it (typically the 
> received PDU).
> 
> Do you have the extended operation code ?

The client code is locked in a private Gitlab repo but we may be able to 
convince my employer to donate it or open it up.  

The RBAC overlay (server side) has recently been added to OpenLDAP contrib 
which will be part of the 2.5 codebase.

Which brings the question - where does the client belong?  Should it be in 
Fortress core, API, somewhere else?

WDYT?

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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
> 

Nice catch Stefan and thanks for letting me know.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

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, thanks for the help.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

> 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/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/impl/UserDAO.java):
>> ```
>> BindResponse bindResponse = bind( ld, userDn, user.getPassword() );
>> Control cont = bindResponse.getControls().get( (new 
>> PasswordPolicyRequestImpl()).getOid() );
> 
> better use PasswordPolicyRequest.OID
> 

Done

> 
>> if ( control == null ){ … }
>> PasswordPolicyResponse respCtrl = ((PasswordPolicyDecorator)control 
>> ).getDecorated();
>> if (respCtrl.hasResponse()){
>> ...
>> if (respCtrl.getResponse().getTimeBeforeExpiration() > 0 ){
>> …
>> if (respCtrl.getResponse().getGraceAuthNRemaining() > 0 ){
>> …
>> ```
>> The 2.x way 
>> [PasswordPolicyResponseTest](https://github.com/apache/directory-ldap-api/blob/master/ldap/extras/codec/src/test/java/org/apache/directory/api/ldap/extras/controls/ppolicy/PasswordPolicyResponseTest.java):
>> ```
>> PasswordPolicyResponseFactory factory = ( PasswordPolicyResponseFactory ) 
>> codec.getResponseControlFactories().
>> get( PasswordPolicyResponse.OID );
>> PasswordPolicyResponse passwordPolicyResponse = factory.newControl();
>> factory.decodeValue( passwordPolicyResponse, bb.array() );
>> assertEquals( 1, passwordPolicyResponse.getTimeBeforeExpiration() );
>> assertEquals( 1, passwordPolicyResponse.getPasswordPolicyError().getValue() 
>> );
>> ```
>>  Before we passed the bind response into the factory.
> 
> In 2.0, you should be able to do something like :
> 
> 
>  BindResponse bindResponse = connection.bind( bindRequest );
> 
>  PasswordPolicyResponse passwordPolicyResp = ( PasswordPolicyResponse ) 
> bindResponse.getControls().get( PasswordPolicyRequest.OID );
> 
> then access the PasswordPolicyResponse fields directly:
> 
>  passwordPolicyResp.getTimeBeforeExpiration()
> 
> etc.

Cool, I’m doing this now and it works great.

Thanks

—
Shawn


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

The debugger tells me that api request controls are loaded in 
[StockCodecFactoryUtil](https://github.com/apache/directory-ldap-api/blob/master/ldap/codec/core/src/main/java/org/apache/directory/api/ldap/codec/StockCodecFactoryUtil.java)

So, I added my RelaxControl into the api code space, and added this blurb to 
StockCodecFactoryUtil class:

```
ControlFactory relaxControlFactory = new RelaxControlFactory( 
apiService );
requestControlFactories.put( relaxControlFactory.getOid(), relaxControlFactory 
);
```

Once registered the control is found by the runtime and things become … well 
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-6CF9-40B7-8BC4-FCE60E40684E%40apache.org%3E)
> 
> I added support to use the Relax Control to the fortress core code base.
> 
> Moving onto 2.x API this control this code is now broken.
> 
> Specifically, I get this error when adding the control to an ldap request:
> 
> ```
> : ERR_08002_CANNOT_FIND_CONTROL_FACTORY failed to find a control factory for 
> control OID: 1.3.6.1.4.1.4203.666.5.12 
> 2021-06-23 14:36:023 WARN  LdapNetworkConnection:2478 - 
> org.apache.directory.api.asn1.EncoderException: 
> ERR_08002_CANNOT_FIND_CONTROL_FACTORY failed to find a control factory for 
> control OID: 1.3.6.1.4.1.4203.666.5.12
> org.apache.mina.filter.codec.ProtocolEncoderException: 
> org.apache.directory.api.asn1.EncoderException: 
> ERR_08002_CANNOT_FIND_CONTROL_FACTORY failed to find a control factory for 
> control OID: 1.3.6.1.4.1.4203.666.5.12
> ```
> 
> Revisiting this example:
> http://directory.apache.org/api/internal-design-guide/13-controls.html
> 
> I noticed that the decorator and factory classes weren’t implemented in my 
> solution.  Actually, as I recall, I did add them, but realized they weren’t 
> needed (with 1.x) and so I removed them.
> 
> I’ve since readded them:
> 
> 1. 
> [RelaxControlFactory](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlFactory.java)
> 2. 
> [RelaxControlDecorator](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlDecorator.java)
> 
> To the existing two:
> 
> 3. 
> [RelaxControl](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControl.java)
> 
> 4. 
> [RelaxControlImpl](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlImpl.java)
> 
> During the readding of the decorator and factory, I also noticed that the 
> example implentation referenced above does not match its associated 
> interfaces, i.e. has changed since 1.x.  
> 
> So, I hacked a bit more to get my code to compile knowing that it's probably 
> not right and guess what -- it isn’t.
> 
> Same error as above.  
> 
> Any help getting past this one is appreciated.
> 
> Still poking around 2.0 codebase to find viable example (for 2.0), and will 
> keep looking.
> 
> Thanks
> 
> —
> Shawn
> 


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

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 base.

Moving onto 2.x API this control this code is now broken.

Specifically, I get this error when adding the control to an ldap request:

```
: ERR_08002_CANNOT_FIND_CONTROL_FACTORY failed to find a control factory for 
control OID: 1.3.6.1.4.1.4203.666.5.12 
2021-06-23 14:36:023 WARN  LdapNetworkConnection:2478 - 
org.apache.directory.api.asn1.EncoderException: 
ERR_08002_CANNOT_FIND_CONTROL_FACTORY failed to find a control factory for 
control OID: 1.3.6.1.4.1.4203.666.5.12
org.apache.mina.filter.codec.ProtocolEncoderException: 
org.apache.directory.api.asn1.EncoderException: 
ERR_08002_CANNOT_FIND_CONTROL_FACTORY failed to find a control factory for 
control OID: 1.3.6.1.4.1.4203.666.5.12
```

Revisiting this example:
http://directory.apache.org/api/internal-design-guide/13-controls.html

I noticed that the decorator and factory classes weren’t implemented in my 
solution.  Actually, as I recall, I did add them, but realized they weren’t 
needed (with 1.x) and so I removed them.

I’ve since readded them:

1. 
[RelaxControlFactory](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlFactory.java)
2. 
[RelaxControlDecorator](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlDecorator.java)

To the existing two:

3. 
[RelaxControl](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControl.java)

4. 
[RelaxControlImpl](https://github.com/apache/directory-fortress-core/blob/FC-238/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlImpl.java)

During the readding of the decorator and factory, I also noticed that the 
example implentation referenced above does not match its associated interfaces, 
i.e. has changed since 1.x.  

So, I hacked a bit more to get my code to compile knowing that it's probably 
not right and guess what -- it isn’t.

Same error as above.  

Any help getting past this one is appreciated.

Still poking around 2.0 codebase to find viable example (for 2.0), and will 
keep looking.

Thanks

—
Shawn


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

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

[Shawn McKinney]

Found a better test to follow.

[AbstractPasswordPolicyResponder](https://github.com/apache/directory-ldap-api/blob/master/ldap/client/api/src/main/java/org/apache/directory/ldap/client/template/AbstractPasswordPolicyResponder.java)


Processing response control like this:

```
protected PasswordPolicyResponse getPwdRespCtrl(BindResponse resp )
{
  Control control = resp.getControls().get( PasswordPolicyResponse.OID );
  return ( PasswordPolicyResponse ) control;
}
```

And then coaxing out the info is straightforward:

```
if ( respCtrl != null ){
…

if ( respCtrl.getTimeBeforeExpiration() > 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://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/impl/UserDAO.java):
> 
> ```
> BindResponse bindResponse = bind( ld, userDn, user.getPassword() );
> Control cont = bindResponse.getControls().get( (new 
> PasswordPolicyRequestImpl()).getOid() );
> if ( control == null ){ … }
> 
> PasswordPolicyResponse respCtrl = ((PasswordPolicyDecorator)control 
> ).getDecorated();
> 
> if (respCtrl.hasResponse()){
> ...
> if (respCtrl.getResponse().getTimeBeforeExpiration() > 0 ){
> …
> 
> if (respCtrl.getResponse().getGraceAuthNRemaining() > 0 ){
> …
> ```
> 
> 
> The 2.x way 
> [PasswordPolicyResponseTest](https://github.com/apache/directory-ldap-api/blob/master/ldap/extras/codec/src/test/java/org/apache/directory/api/ldap/extras/controls/ppolicy/PasswordPolicyResponseTest.java):
> 
> ```
> PasswordPolicyResponseFactory factory = ( PasswordPolicyResponseFactory ) 
> codec.getResponseControlFactories().
> get( PasswordPolicyResponse.OID );
> PasswordPolicyResponse passwordPolicyResponse = factory.newControl();
> factory.decodeValue( passwordPolicyResponse, bb.array() );
> 
> assertEquals( 1, passwordPolicyResponse.getTimeBeforeExpiration() );
> assertEquals( 1, passwordPolicyResponse.getPasswordPolicyError().getValue() );
> ```
> 
> Before we passed the bind response into the factory.  
> 
> The 2.0 tests uses a bytebuffer to decode the response.  I don’t understand 
> how to do this within the context of an authN event.
> 
> Any ideas here?
> 
> Thanks
> 
> —
> Shawn
> 
> 
> 


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migrate to 2.0 API

[Shawn McKinney]

> 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:
>> PooledObjectFactory poolFactory = new 
>> ValidatingPoolableLdapConnectionFactory( config );
>> 
> 
>> But can’t use these://adminPool.setWhenExhaustedAction( 
>> GenericObjectPool.WHEN_EXHAUSTED_GROW );
> 
> I the changelog
> https://commons.apache.org/proper/commons-pool/changes-report.html I found
> 
>> Remove WhenExhuastedAction.GROW since it is equivalent to
> WhenExhuastedAction.FAIL with a maxActive value of Integer.MAX_VALUE.
> 
>> //adminPool.setMaxActive( max );
> 
> According to the git log this was rnamed to maxTotal
> 
> https://github.com/apache/commons-pool/commit/c7d527543868ea2835e609e072b8a6423d4d99cb
> 
> 
> If I understand correctly the new way it set maxTotal to a large number
> (Integer.MAX_VALUE).

Hi Stefan, thanks for taking the time to look into this...

Here’s where I’m at:

pool.setMaxTotal( max );
pool.setBlockWhenExhausted( isBlocking );
pool.setMaxWaitMillis( maxWait );

As you pointed out, now use maxTotal.  

Having thought about this a bit more, I’m hesitant to allow a pool to grow 
unconstrained or to allow it to block for an unlimited time period, waiting for 
a connection to free up.

Having a reasonable maxTotal and allowing to block for … at most say 10 seconds 
seems to be sensible way of handling this.

—
Shawn



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Migrate to 2.0 API

[Shawn McKinney]

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):

https://github.com/apache/directory-fortress-core/tree/FC-238

And most of the tests pass.  

But, there are several problem areas, documented here:
https://issues.apache.org/jira/browse/FC-238

Taking #1 from this list:

// TODO: FIXME #1
I switched from this://PoolableObjectFactory 
poolFactory = new ValidatingPoolableLdapConnectionFactory( config );

To:
PooledObjectFactory poolFactory = new 
ValidatingPoolableLdapConnectionFactory( config );

But can’t use these://adminPool.setWhenExhaustedAction( 
GenericObjectPool.WHEN_EXHAUSTED_GROW );
//adminPool.setMaxActive( max );

Not sure what the workaround is for these two settings.  

Any ideas?

—
Shawn


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Relax Control and password policies

[Shawn McKinney]

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 detail.

The second change does apply here.  It requires following the RFC standard for 
client induced changes to the operational attributes on the user entry that 
help manage pw polices.

Specifically, when editing values like pwdLockout and pwdPolicySubentry, the 
relax control must be included in the request before the server will make any 
changes.

I’ve created a ticket to carry these associated changes into fortress:

[Support Relax Control](https://issues.apache.org/jira/browse/FC-291)

What may be interesting here is that I didn't find this control as an existing 
API support, per:

http://directory.apache.org/api/user-guide/6.7-control.html#managedsait

So, I built one.  I followed this good example:

http://directory.apache.org/api/internal-design-guide/13-controls.html

The code’s in a branch:

[RelaxControl 
(interface)](https://github.com/apache/directory-fortress-core/blob/relax/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControl.java)

[RelaxControlImpl]
(https://github.com/apache/directory-fortress-core/blob/relax/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlImpl.java)

[RelaxControlDecorator]
(https://github.com/apache/directory-fortress-core/blob/relax/src/main/java/org/apache/directory/fortress/core/ldap/RelaxControlDecorator.java)

I’m fine with maintaining this as part of the fortress core but thought it 
might useful as part of the API.  

Let me know if this should be included as part of the API codebase.

Thanks,

—
Shawn


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapNetworkConnection. add eating exceptions

[Shawn McKinney]

> On Apr 5, 2021, at 4:12 PM, Emmanuel Lécharny  wrote:
> 
> Stefan is correct.
> 
> There was a discussion about how to react to server's errors. We wanted to 
> distinguish between technical errors and logical errors (ie server responses 
> containing LdapResult which is not SUCCESS).
> 
> In these last cases, throwing an exception would have make it a bit more 
> complicated for the client to handle the root cause, as we would have had 
> either to map an exception by error type, or include the response into the 
> exception, and expecting the client to pull it out of the exception to do 
> something with it. We found it more convenient to let the client directly 
> deal with the LapResult in the Response and act upon its need.
> 

Makes sense.  Thanks for the background story.  It helps to understand the why 
along with the how it works.

—
Shawn

> And I agree with Stefan too: if it's not clear, then more doco is necessary.
> 
> On 05/04/2021 21:32, Stefan Seelmann wrote:
>> Hi Shawn,
>> 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 also return
>> a raw XyzResponse object. Those only throw an exception if a network
>> level exceptions happens. But if the LDAP server properly returns a
>> response (be is positive or negative) the raw response is returned to
>> the caller and the caller has to inspect it.
>> There are other methods like add(Entry) or delete(Dn) or modify(Dn,
>> Modification) which return void. For those methods it's different and
>> 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 that it looks surprising, propbably we should improve the javadoc?
>> Kind Regards,
>> Stefan
>> On 4/5/21 8:30 PM, Shawn McKinney wrote:
>>> 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 addRequest = new AddRequestImpl();
>>> addRequest.setEntry( entry );
>>> if ( setManagedDsa )
>>> {
>>>ManageDsaIT mControl =  new ManageDsaITImpl();
>>>mControl.setCritical( true );
>>>addRequest.addControl( mControl );
>>> }
>>> AddResponse response = connection.add( addRequest );
>>> ```
>>> 
>>> FWIW I’ve also done it this way:
>>> 
>>> ```
>>> addRequest.addControl( new ManageDsaITImpl(); );
>>> ```
>>> 
>>> With this newly modified code I wouldn’t expect to get an error from 
>>> server, but let’s set that concern aside for a moment.
>>> 
>>> What I REALLY don't expect is for the server exception to be eaten by the 
>>> API.
>>> 
>>> It happens line 566 of class (v1.3):
>>> 
>>> 
>>>   } else {
>>>   LOG.debug("Add failed : {}", addResponse);
>>> }
>>> 
>>> I’ve stepped through it, the server returns in response to the add (with 
>>> pwpolicy operational attr):
>>> 
>>> ```
>>> Ldap Result
>>> Result code : (CONSTRAINT_VIOLATION) constraintViolation
>>> Matched Dn : ''
>>> Diagnostic message : 'pwdPolicySubentry: no user modification allowed’
>>> ```
>>> 
>>> A more complete excerpt of LDAP API code add method:
>>> 
>>> 
>>> ```
>>> LdapNetworkConnection
>>> public AddResponse add(AddRequest addRequest) throws LdapException {
>>> ...
>>> 
>>> try {
>>> AddResponse addResponse = (AddResponse)addFuture.get(this.timeout, 
>>> TimeUnit.MILLISECONDS);
>>> if (addResponse == null) {
>>> LOG.error("Add failed : timeout occurred");
>>> throw new LdapException("TimeOut occurred");
>>> } else {
>>> if (addResponse.getLdapResult().getResultCode() == 
>>> ResultCodeEnum.SUCCESS) {
>>> LOG.debug("Add successful : {}&

Re: LdapNetworkConnection. add eating exceptions

[Shawn McKinney]

> 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 also return
> a raw XyzResponse object. Those only throw an exception if a network
> level exceptions happens. But if the LDAP server properly returns a
> response (be is positive or negative) the raw response is returned to
> the caller and the caller has to inspect it.
> 
> There are other methods like add(Entry) or delete(Dn) or modify(Dn,
> Modification) which return void. For those methods it's different and
> the response from the server is processed by
> ResultCodeEnum.processResponse() which throws LDAP specific exceptions
> for non-successfule responses.
> 

You hit the nail on the head Stefan.  That’s what happened here.  Before, was 
using the void returning methods and this was not observed.

Changed to using the raw methods, on order to send the ‘relax control’ (which I 
don’t know how to attach to the add/modify).

> If you use the raw request/response methods you can use that utility
> method too if you like.
> 

Very good info.  That’s what I’ll do.

> I agree that it looks surprising, propbably we should improve the javadoc?

Yeah, would be worth pointing out me think too.  Thanks for chiming in Stefan.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

LdapNetworkConnection. add eating exceptions

[Shawn McKinney]

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 addRequest = new AddRequestImpl();
addRequest.setEntry( entry );
if ( setManagedDsa )
{
   ManageDsaIT mControl =  new ManageDsaITImpl();
   mControl.setCritical( true );
   addRequest.addControl( mControl );
}
AddResponse response = connection.add( addRequest );
```

FWIW I’ve also done it this way:

```
addRequest.addControl( new ManageDsaITImpl(); );
```

With this newly modified code I wouldn’t expect to get an error from server, 
but let’s set that concern aside for a moment.

What I REALLY don't expect is for the server exception to be eaten by the API. 

It happens line 566 of class (v1.3):


  } else {
  LOG.debug("Add failed : {}", addResponse);
}

I’ve stepped through it, the server returns in response to the add (with 
pwpolicy operational attr):

```
Ldap Result
Result code : (CONSTRAINT_VIOLATION) constraintViolation
Matched Dn : ''
Diagnostic message : 'pwdPolicySubentry: no user modification allowed’
```

A more complete excerpt of LDAP API code add method:


```
LdapNetworkConnection
public AddResponse add(AddRequest addRequest) throws LdapException {
...

try {
AddResponse addResponse = (AddResponse)addFuture.get(this.timeout, 
TimeUnit.MILLISECONDS);
if (addResponse == null) {
LOG.error("Add failed : timeout occurred");
throw new LdapException("TimeOut occurred");
} else {
if (addResponse.getLdapResult().getResultCode() == 
ResultCodeEnum.SUCCESS) {
LOG.debug("Add successful : {}", addResponse);
} else {
LOG.debug("Add failed : {}", addResponse);
}

return addResponse;
}
…
```

Please advise on if you think this is a bug (eating exception).  I’ll follow-up 
with another thread on the *why* the server's returning the exception in the 
first place but I need to investigate a bit more (may be problem on server 
OpenLDAP 2.5.3 beta).

—
Shawn


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Shawn McKinney]

> 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 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 don't want to check connections while fetching one, then you are on 
>>> your own (ie, deal with the consequences of a bad connection).
>> Again, I must disagree.  Connections aren’t stable, subjected to env 
>> conditions and we can never assume a connection is good. 
> 
> You *can* assume it's good, and react exceptionally if it's not. That the 
> fastest way to deal with potential bad connections, if you want to avoid a 
> check every time you pull a connection from the pool. (but see later for 
> another option)

There are 150 locations in fortress core where an ldap connection is being 
pulled from the pool. No way I want to revisit all of that code. 

> 
> Something in the API chain must do the job of testing and reconnect, every 
> time it’s pulled from the pool.
> 
> This is exactly what the testOnBorrow does ;-) But it's costly... (see later 
> for another option)
> 
>> Now, having said that, that’s exactly what I’m observing currently, with the 
>> test on borrow flag turned off.
>> Let me explain the scenario:
>> 1. Start server
>> 2. Start client
>> This initializes a connection pool which creates and stores exactly 1 
>> connection (min 1, max1 )
>> 3. Set breakpoint in client on pool.getConnection method
>> 4. Restart the server.
>> 5. Client performs ldap op which triggers the breakpoint on getConnection
>> 6. Server at this point still hasn’t any connections with the client.  The 
>> client ‘thinks’ it has connections in the pool, but these were broken on 
>> step 4.
>> 7. Step over the getConnection which then triggers the commons pool to 
>> execute:
>> ```
>> GenericObjectPool._factory.activateObject(latch.getPair().value)
>> ```
>> 8. A connection is made with the server, along with bind
>> ```
>> 6058e163 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:35246 (IP=127.0.0.1:389)
>>  [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
>> method=128
>>  [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
>> mech=SIMPLE ssf=0
>>  [exec] 6058e163 conn=1000 op=0 RESULT tag=97 err=0 duration=1.667ms
>> ```
>> 9. Client continues with its ldap op successfully and is never the wiser 
>> that the connections were all forcibly closed on server restart.
>> This is EXACTLY what I want to see all of which is done without the test on 
>> borrow eliminating the extraneous search on every connection retrieval.
> 
> So that would mean we have some kind of 'retry' on connection operation: if 
> it fails, then let's assume the connection is broken, and redo it with a 
> fresh connection.
> 

Yes, that’s what’s happening.  
In the Commons pool lib, this is the block that gets executed:

``` this._factory.activateObject(latch.getPair().value);
if (this._testOnBorrow && 
!this._factory.validateObject(latch.getPair().value)) {
throw new Exception("ValidateObject failed");
}
```

In the first line above, activateObject, this code gets called, from our 
AbstractPoolableLdapConnectionFactory class:

```
public void activateObject(LdapConnection connection) throws LdapException {
  LOG.debug("Activating {}", connection);
  if (!connection.isConnected() ||
  !connection.isAuthenticated()) {
LOG.debug("rebind due to connection dropped on {}", connection);
this.connectionFactory.bindConnection(connection);
}
```

The code performs a rebind which renews the connection.

All of this with testOnBorrow being false! 

So, I’m still scratching my head figuring why we need this secondary level that 
is wasting a round trip to the server.


> The problem is that the pool is passive: it does not react to any connection 
> event, like a connection closure. OTOH, when a connection is properly closed 
> by the server (ie an NoticeOfDisconnect - aka NoD - is generated by the 
> server), the connection should process it and die. Now we have an issue: the 
> connection is just lying in the pool, not being used by any client, so there 
> is a missing step: removing the connection from the pool in this very case. 
> That can be something we can add to the current LDAP pool.
> 
> Note that if the server does not send a NoD, you 

Re: LdapConnectionPool.getConnection doing extraneous search?

[Shawn McKinney]

> 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,
> and returns the result.
> 
> When the method execution fails with a specific error (connection error)
> it invalidates the object in the pool, borrows a new one, and retries.

Hi Stefan, thanks for weighing in.

Potentially, yes.  I’m still trying to determine if the connection pool 
behavior is going to be reliable with test on borrow turned off.  

From observations it does appear to, but I don’t understand ‘how’ yet and so 
remain skeptical.

I’m definitely not satisfied with the test on borrow extra round trip and so we 
may have to go the dynamic proxy route.

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Shawn McKinney]

> 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 
> don't want to check connections while fetching one, then you are on your own 
> (ie, deal with the consequences of a bad connection).

Again, I must disagree.  Connections aren’t stable, subjected to env conditions 
and we can never assume a connection is good.  Something in the API chain must 
do the job of testing and reconnect, every time it’s pulled from the pool.

Now, having said that, that’s exactly what I’m observing currently, with the 
test on borrow flag turned off.

Let me explain the scenario:

1. Start server
2. Start client

This initializes a connection pool which creates and stores exactly 1 
connection (min 1, max1 )

3. Set breakpoint in client on pool.getConnection method

4. Restart the server.

5. Client performs ldap op which triggers the breakpoint on getConnection

6. Server at this point still hasn’t any connections with the client.  The 
client ‘thinks’ it has connections in the pool, but these were broken on step 4.

7. Step over the getConnection which then triggers the commons pool to execute:

```
GenericObjectPool._factory.activateObject(latch.getPair().value)
```

8. A connection is made with the server, along with bind

```
6058e163 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:35246 (IP=127.0.0.1:389)
 [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
method=128
 [exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com" 
mech=SIMPLE ssf=0
 [exec] 6058e163 conn=1000 op=0 RESULT tag=97 err=0 duration=1.667ms
```

9. Client continues with its ldap op successfully and is never the wiser that 
the connections were all forcibly closed on server restart.

This is EXACTLY what I want to see all of which is done without the test on 
borrow eliminating the extraneous search on every connection retrieval.

—
Shawn




-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Shawn McKinney]

> 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 going to say.  I’ve tested restarting the 
> server after the pool was created and it seems OK.


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Shawn McKinney]

> 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 you can ask the pool to validate the 
> connection one way or the other. We are probably using 
> LookupLdapConnectionValidator for that purpose:

Hi Emmanuel,

It’s actually sending that dummy search every time, which of course isn’t good. 
 Here’s the code to create the pool:

```
// Create the Admin pool
adminPool = new LdapConnectionPool( poolFactory );
adminPool.setTestOnBorrow( true );
adminPool.setWhenExhaustedAction( GenericObjectPool.WHEN_EXHAUSTED_GROW );
adminPool.setMaxActive( max );
adminPool.setMinIdle( min );
adminPool.setMaxIdle( -1 );
adminPool.setTestWhileIdle( testWhileIdle );
adminPool.setTimeBetweenEvictionRunsMillis( timeBetweenEvictionRunMillis );
```

Notice that ‘setTestOnBorrow' being set to true.

When I flip that switch, the dummy search no longer occurs when connection is 
retrieved, which is `good.

Wonder what we lose.  Recovery from connections being timed out by server or 
reset by intermediaries like routers?  

Must do more testing…

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

LdapConnectionPool.getConnection doing extraneous search?

[Shawn McKinney]

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 (filter and stats enabled) an extra search comes 
through during this invocation:

Begin slapd log trace:

```
[exec] 60566cd5 begin get_filter
[exec] 60566cd5 PRESENT
[exec] 60566cd5 end get_filter 0
[exec] 60566cd5 conn=1010 op=5 SRCH base="" scope=0 deref=3 
filter="(objectClass=*)"
[exec] 60566cd5 conn=1010 op=5 SRCH attr=1.1
[exec] 60566cd5 => test_filter
[exec] 60566cd5 PRESENT
[exec] 60566cd5 <= test_filter 6
[exec] 60566cd5 conn=1010 op=5 SEARCH RESULT tag=101 err=0 duration=0.236ms 
nentries=1 text=
```

It’s performing a null base search with objectClass=* asking for attr ‘1.1'.

What’s going on here?  I expect to see a bind on that connection (the first 
time) but not a search.


Thanks,

—
Shawn
-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Toward a 2.0 GA

[Shawn McKinney]

> 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 load the provided KeyStore, using the 
> paswword that has to be provided too. There are two parameters used to 
> configure the server : ads-keystoreFile that will contain tha path to the 
> KeyStore and ads-certificatePassword (which should most certainly be renamed 
> ads_keyStorePassword)

Hi Emmanuel, 

Thinking out loud here so forgive the naive comment, but shouldn’t the server 
use the a. default Java keystore (if found), or b. what’s passed to it, and 
only if not (a or b) c. create a new?

Thanks,
—Shawn

Re: SASL/EXTERNAL binding

[Shawn McKinney]

> 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 used SASL before and would 
like to learn how.  If we get it to that point and have reusable tests, I’ll 
document it in the user’s manual.

Shawn

Re: Ldap API Custom Controls

[Shawn McKinney]

> 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 enable the API logger containing the BER 
request/response traces?  That’s typically how I debug.  Saves the trouble of 
setting up wireshark.

Re: LDAP API 1.0 status

[Shawn McKinney]

> 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
> (http://directory.staging.apache.org/api/user-guide/5-ldap-security.html
> and the associated pages). My current focus is on SASL, the SSL and
> StartTLS pages are complete - well, unless we have something to add ;-)...
> 
> 
> Feel free to review them !

Out of town this week but will try to get to making another pass next week.

Re: cURRENT uSER gUID XTATUS

[Shawn McKinney]

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 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>>> 
>>> now that you have spent some time reading and fixing the current (and
>>> incomplete) DLAP API User Guide, do you have any general remark related
>>> to its content, structure, or whatever ?
>>> 
>> Overall structure is pretty good.  It’s broken down in a reasonable way -- 
>> basic, advanced, etc, and the subsections are ordered well.  Nav is easy 
>> enough although a (master) table of contents listing all of the pages, 
>> descriptions and status (finished or not) would be helpful.
>> 
>> Content is mixed.  What’s there is quite good but many things not covered.  
>> For example, security isn't covered.  Of course I suggest it be completed 
>> ASAP.  To be fair authN’s covered in the bind/unbind section but SSL/TLS & 
>> authZ isn't. 
> 
> On my list for next week. Call it a new year good resolution :-)
> 
> -- 
> Emmanuel Lecharny
> 
> Symas.com
> directory.apache.org
> 

Re: LDAP API 1.0-GA preparation

[Shawn McKinney]

> 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 !

Hello,

I have completed a first-pass over our LDAP API’s user guide.  The goal was to 
cleanup grammar, spelling, description semantics, and broken links.  I didn’t 
add new content, nor did I alter the structure of any of existing documents.

There are many sections not yet completed but I believe we’re OK for a 1.0 GA 
(although the security sections should be completed soon for obvious reasons).

You can review the updated user’s guide here:
http://directory.staging.apache.org/api/user-guide.html

I really like the story.  It should be emphasized once this release becomes 
public:
http://directory.staging.apache.org/api/user-guide/1.3-apache-ldap-api-rational.html

At the very least we should create a wikipedia page with this as its history.

Let me know if you see any errors that need correcting.

Thanks,
Shawn

Re: API changes impact on ApacheDS, take 6

[Shawn McKinney]

> 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 a case of 
'apertus principiumitis’ (open souritis).  

The predilection of one to code (rather than relaxing) across employer 
sanctioned weekends, holidays and/or vacations on a particular open source 
project. 

:-)

Re: Value classes refactoring

[Shawn McKinney]

> 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 work and explanations.  Let me know if there are 
certain scenarios that need testing to verify functionality.

Shawn