[Announcement] : Apache LDAP API 2.1.4

[Emmanuel Lecharny]

The Apache Directory project is proud to announce the release of the
Apache LDAP API 2.1.4 version !

The Apache Directory LDAP API is an ongoing effort to provide an
enhanced LDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server,
but should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

This is a bug fix release, it conatains a fix in the DN ancestors
management, and a migration to MINA 2.2.2, which supports TLS 1.3.

Here is the fixed issue:

DIRAPI-393 - DN comparison behavior changed after parsing ancestor


Website : https://directory.apache.org/api
Download : https://directory.apache.org/api/downloads-2.html
User's Guide : https://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

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

[Announcement] : Apache LDAP API 2.1.2

[Emmanuel Lecharny]

he Apache Directory project is proud to announce the release of the
Apache LDAP API 2.1.2 version !

The Apache Directory LDAP API is an ongoing effort to provide an
enhanced LDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server,
but should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

This version is a fix, the previous version having been built with
Java 11 and a wrong maven property led to a package that can't be used
with Java 8.

Website : https://directory.apache.org/api
Download : https://directory.apache.org/api/downloads-2.html
User's Guide : https://directory.apache.org/api/user-guide.html


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

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

[Announcement] : Apache LDAP API 2.1.1

[Emmanuel Lecharny]

The Apache Directory project is proud to announce the release of the
Apache LDAP API 2.1.1 version !

The Apache Directory LDAP API is an ongoing effort to provide an
enhanced LDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server,
but should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

This version is now using MINA 2.1.1, which comes with a complete
rewrite of the TLS layer. It also fixes a list of issues:

Improvement:
* https://issues.apache.org/jira/browse/DIRAPI-352 - The Base64
implementation can be removed

Bugs:
* https://issues.apache.org/jira/browse/DIRAPI-348 - NPE when Api
decodes bind response from OpenDJ server 6.0
* https://issues.apache.org/jira/browse/DIRAPI-369 - DSML needsBase64Encoding
* https://issues.apache.org/jira/browse/DIRAPI-379 - NPE on ill formed
error response
* https://issues.apache.org/jira/browse/DIRAPI-380 - Binding using a
DN which RDN is complex may fail


Website : https://directory.apache.org/api
Download : https://directory.apache.org/api/downloads-2.html
User's Guide : https://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

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

[ANNOUNCE] Apache Directory LDAP API 2.0.0.AM4 released

[Emmanuel Lecharny]

The Apache Directory Team is proud to announce the availability of version
2.0.0.AM4 of the Apache Directory LDAP API, the forth milestone toward a
2.0 version of the Apache LDAP API.

The Apache Directory LDAP API is an ongoing effort to provide an
enhanced LDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server, but
should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

We wanted to cut a GA, but some urgent fixes were needed, coupled with
some MINA release that also fixes serious issues. In any case, this
releases fixes DIRAPI-342 (race condition when we close a connection)
and DIRAPI-343 (Some missing Syntaxes), plus DIRAPI-328 (API
inconsistencies).

Those using the Apache LDAP API 2.0.0.AM3 version should switch to this
version.

Website : http://directory.apache.org/api
Download : http://directory.apache.org/api/downloads-2.html
User's Guide : http://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

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

Re: NPE in ERR_04122_SSL_CONTEXT_INIT_FAILURE Failed to initialize the SSL context

[Emmanuel Lecharny]

Good to see you have found the root cause of your issue. May I ask you to
fill a JIRA for the NPE so that we don’t forget to fix it?

Many thanks!

Le ven. 26 avr. 2019 à 17:55, Michael Barkdoll  a
écrit :

> I tried removing the valid=10s from the docker swarm dns resolver to see if
> it makes a difference, but I still received an error [1] after several ldap
> successfully logins.  I noticed this error states:
>
> org.apache.mina.core.RuntimeIoException: Failed to get the session.
> Caused by: java.net.NoRouteToHostException: No route to host
>
> So, I made a bash script to check if there was any routing issues.
>
> ```
> while true; do
> nc -w 3 -z -v ad.uni.edu 636; echo $?
> sleep 1;
> done
> ```
> Output:
> Warning: inverse host lookup failed for 10.10.0.19: Unknown host
> ad.uni.edu [10.10.0.19] 636 (?) : No route to host
>
> I think one of the servers in the DNS entry is bad! I had hard coded Apache
> Guacmaole to only connect to a good one, but I think the Apache Ldap is
> doing a bind with the DNS entry provided by the ldap-user-base-dn:
> dc=ad,dc=uni,dc=edu in apache guacamole.  I'm going to email our windows
> folks and see if they can get that server out of the DNS entry since I
> think it is the cause.
>
> [1]
> https://gist.github.com/michaelbarkdoll/bc8ae3b13b1a20dd4ac259d6c20c011c
>
> Michael Barkdoll
>
>
> On Fri, Apr 26, 2019 at 10:06 AM Michael Barkdoll 
> wrote:
>
> > The ldap server is active directory 2016.
> >
> > The code that is using the directory ldap api is from a tomcat .WAR
> > (apache guacamole) [1].  I forked [1] and customized the jira/234 PR to
> > support ldap and nginx websocket load balancing in this repo [2]
> according
> > to apache guacamole's documentation.   I'm using docker swarm to set up
> an
> > overlay network between an nginx reverse proxy to two separate apache
> > guacamole tomcat servlets.  The nginx reverse proxy nginx.conf file is
> > provided here [3].
> >
> > You're correct that userX log entries are successful ldap login attempts
> > that I do to the tomcat .WAR and then I immediately logout and back in
> > another time until the error occurs.  What would be causing the handshake
> > to not end?
> >
> > [1] https://github.com/apache/guacamole-client
> > [2] https://github.com/michaelbarkdoll/guacamole-client/tree/jira/234
> > [3]
> > https://gist.github.com/michaelbarkdoll/d78614635fa0432ab08100d05f1a4919
> >
> > Michael Barkdoll
> >
> >
> >
> > On Fri, Apr 26, 2019 at 12:26 AM Stefan Seelmann <
> m...@stefan-seelmann.de>
> > wrote:
> >
> >> On 4/26/19 7:09 AM, Emmanuel Lecharny wrote:
> >> >> ERR_04122_SSL_CONTEXT_INIT_FAILURE Failed to initialize the SSL
> context
> >> >>
> >> >> java.lang.NullPointerException: null
> >> >> at
> >> >>
> >> >>
> >>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:689)
> >> >
> >> >
> >> > It seems, from the code, that the connection times out. The NPE is
> >> > infortunate -and we will fix it- but it’s just masking the real cause:
> >> the
> >> > handshake never ends.
> >> >
> >> > What is the scenario you are running?
> >>
> >> Especially, which LDAP server do you use?
> >>
> >> In error3.txt and error4.txt I see multiple logs messages "User "userX"
> >> successfully authenticated". Does that mean in those cases the
> >> connection to LDAP worked and it only fails randomly? It seems there are
> >> multiple threads involved, so maybe it's a concurrency issue...
> >>
> >>
> >>
> >>
> >>
>
-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: NPE in ERR_04122_SSL_CONTEXT_INIT_FAILURE Failed to initialize the SSL context

[Emmanuel Lecharny]

Le ven. 26 avr. 2019 à 17:07, Michael Barkdoll  a
écrit :

> The ldap server is active directory 2016.
>
> The code that is using the directory ldap api is from a tomcat .WAR (apache
> guacamole) [1].  I forked [1] and customized the jira/234 PR to support
> ldap and nginx websocket load balancing in this repo [2] according to
> apache guacamole's documentation.   I'm using docker swarm to set up an
> overlay network between an nginx reverse proxy to two separate apache
> guacamole tomcat servlets.  The nginx reverse proxy nginx.conf file is
> provided here [3].
>
> You're correct that userX log entries are successful ldap login attempts
> that I do to the tomcat .WAR and then I immediately logout and back in
> another time until the error occurs.  What would be causing the handshake
> to not end?



Let’s assume it’s a handshake error: can you run the test adding
-Djavax.net.debug=all ? ( warning: verbosity expected...)

>
>
> [1] https://github.com/apache/guacamole-client
> [2] https://github.com/michaelbarkdoll/guacamole-client/tree/jira/234
> [3]
> https://gist.github.com/michaelbarkdoll/d78614635fa0432ab08100d05f1a4919
>
> Michael Barkdoll
>
>
>
> On Fri, Apr 26, 2019 at 12:26 AM Stefan Seelmann 
> wrote:
>
> > On 4/26/19 7:09 AM, Emmanuel Lecharny wrote:
> > >> ERR_04122_SSL_CONTEXT_INIT_FAILURE Failed to initialize the SSL
> context
> > >>
> > >> java.lang.NullPointerException: null
> > >> at
> > >>
> > >>
> >
> org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:689)
> > >
> > >
> > > It seems, from the code, that the connection times out. The NPE is
> > > infortunate -and we will fix it- but it’s just masking the real cause:
> > the
> > > handshake never ends.
> > >
> > > What is the scenario you are running?
> >
> > Especially, which LDAP server do you use?
> >
> > In error3.txt and error4.txt I see multiple logs messages "User "userX"
> > successfully authenticated". Does that mean in those cases the
> > connection to LDAP worked and it only fails randomly? It seems there are
> > multiple threads involved, so maybe it's a concurrency issue...
> >
> >
> >
> >
> >
>
-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ANNOUNCE] Apache LDAP API 2.0.0AM2 released

[Emmanuel Lecharny]

The Apache Directory Team is proud to announce the availability of version
2.0.0.AM2 of the Apache Directory LDAP API, the second milestone toward a
2.0 version of the Apache LDAP API
The Apache Directory LDAP API is an ongoing effort to provide an
enhancedLDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server, but
should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

This is a bug fix release, which greatly improves the performance of schema
management (which will be visible in teh next Apache Directory Studio release)

Those using the Apache LDAP API 2.0.0.AM1 version should switch to this
version

Website : http://directory.apache.org/api
Download : http://directory.apache.org/api/downloads-2.html

User's Guide : http://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Annoucement] CVE-2018-1337 Plaintext Password Disclosure in Secured Channel

[Emmanuel Lecharny]

CVE-2018-1337: Plaintext Password Disclosure in Secured Channel

Severity: Critical

Vendor: The Apache Software Foundation

Versions Affected:
Apache LDAP API 1.0.0

Description:
A bug in the way the SSL Filter was setup made it possible for
another thread to use the connection before the TLS layer has been
established, if the connection has already been used and put back
in a pool of connections, leading to leaking any informations
contained in this request (including the credentials when sending
a BIND request)

Mitigation:

Users are urged to use this 1.0.2 version ASAP. There is no impact
in their application, the API remains unchanged.

The previous version (LDAP API 1.0.1) was a workaround for this
problem.

History:
2018-05-15 Original advisory

Credit:
This issue has been reported by Wei Deng (Datastax), the initial
workaround was proposed by Mike Adamson (Datastax) and the further
investigations/tests/verification were conducted by Wei Deng,
Mike Adamson, Jeremiah Kordan (Datastax) and Ben Coverston (Datastax).


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Announcement] : Apache LDAP API 1.0.2

[Emmanuel Lecharny]

The Apache Directory LDAP API is an ongoing effort to provide an
enhancedLDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server, but
should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

This is a bug fix release.

We urge any user to switch to this version as soon as possible.

Website : http://directory.apache.org/api
Download : http://directory.apache.org/api/downloads.html
User's Guide : http://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharnywww.iktek.com

[Announcement] Apache LDAP API 1.0.2 released

[Emmanuel Lecharny]

The Apache Directory Team is proud to announce the availability of version
1.0.2 of the Apache Directory LDAP API.

The Apache Directory LDAP API is an ongoing effort to provide an
enhancedLDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server, but
should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network.

This is a bug fix release.

We urge any user to switch to this version as soon as possible.

Website : http://directory.apache.org/api
Download : http://directory.apache.org/api/downloads.html
User's Guide : http://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharnywww.iktek.com



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Fast openldap schema parser : completed

[Emmanuel Lecharny]

Ok, I have fixed Studio to have it working fine with the modified API.

It seems to be faster to open now (15s when launched from Eclipse, against 21" 
for a previous version).

Stefan, can you confirm that it's the case ?

Thanks !

On 2018/05/16 08:25:42, Emmanuel Lécharny <elecha...@gmail.com> wrote: 
> Hi !
> 
> I finally committed the new parser. I did my best to have the same API, 
> so ou can use it as if it were the previous version, except that it does 
> not use AntLR anymore.
> 
> The final performance results :
> 
> new parser, core schema parsed 100 000 times : 31s
> old parser, core schema parsed  10 000 times : 100s
> 
> ratio : 32 times faster (it's a bit slower than what I said in my 
> previous mails, but I have added various checks that slow down the 
> parser - mainly checks on OID validity -.
> 
> 
> Radovan, you are free to check with your various LDAP server if the code 
> is ok for you, and if not, I'm ready to fix it.
> 
> Side notes :
> - I'm now using static methods for the various schema parsers, so there 
> is no synchronization anymore
> - I found *many* errors in the previous implementation...
> - the Strict mode is not as strict as it could be : we typically accept 
> OID macros (that allows us to have things like "attributeType ( 
> MyRootOid:2.3.4 ...)" to be used, where 'MyRootOid' is defined using a 
> ObjectIdentifier element. This is ultra convenientt, and does not put us 
> at risk.
> - The code has been pushed in the API 2.0 branch.
> 
> I haven't yet tested Studio with this new code, this is soemthing I'll 
> do soon.
> 
> Hope you'll find that convenient !
> -- 
> Emmanuel Lecharny
> 
> Symas.com
> directory.apache.org
> 
> 

Re: Qustion regarding schema quirk mode

[Emmanuel Lecharny]

That will be when I’ll be back from vacations :-)


Le lun. 23 avr. 2018 à 12:40, Radovan Semancik <
radovan.seman...@evolveum.com> a écrit :

> Hi,
>
> As far as I remember it should also contain:
>
> * Allow (pretty much any) string as OID. E.g. "whatever-oid" is often
> used instead of real OID by Sun/Oracle servers. And I have even see it
> recommended practice.
>
> * Do not die when some of the schema parts is not there at all. E.g.
> Active Directory does not have SYNTAX definitions at all. It is OK to
> have these parts as null in the parsed schema, just the schema parser
> must not die on NPE or similar error during parsing.
>
> Once you have the new parser working for your scenarios I can update my
> connector to a new Dir API version. And the I can run the tests with my
> private directory server ZOO.
>
> --
> Radovan Semancik
> Software Architect
> evolveum.com
>
>
>
> On 04/15/2018 11:03 PM, Emmanuel Lécharny wrote:
> > Hi guys,
> >
> > I'm trying to speedup the schema parsing (it's currently quite slow, due
> > to the 3 embedded Antlr parsers we use).
> >
> > We use a quirksMode to be able to process more than just the RFC 4512
> > syntax. AFAICT, here are the relaxed rules :
> >
> > o Allow prefixed numericOID, like attributeType ( DUAConfSchemaOID:1.0
> > NAME 'defaultServerList' (assuming we have a DUAConfSchemaOID
> > definedusing an objectidentifier definition)
> >
> > o Avoid checking references (SUP, SYNTAX) between schema elements
> >
> > o Allow the presence of special chars like '.', '_', ';', ':' and '#' in
> > a NAME
> >
> > o Null OID are accepted for DitStructureRules
> >
> >
> > Is there anything I'm missing ?
> >
> > Thanks !
> >
>
>
> --
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Ldap API Custom Controls

[Emmanuel Lecharny]

It's a bit tricky...

What control do you want to implement? Do you have a description ?

Le dim. 3 sept. 2017 à 15:58, Chris Pike  a écrit :

> Hi,
>
> I am trying to add a custom control. I started by creating a class that
> implements "org.apache.directory.api.ldap.model.message.Control" and
> passing an instance into my request. This didn't seem to work, I'm guessing
> because the value for the control is not passed.
>
> When looking at some of the other controls, I found a bunch of Decorator
> and Factory classes in another package. Do I need to implement those types
> of classes as well? If so, how do I register them? Is there a full example
> of creating a custom control somewhere?
>
> Thanks for any help you can provide.
>
> ~Chris Pike
>
-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Immutable SyntexCheckers

[Emmanuel Lecharny]

Thanks, Stefan.

I'll have a look at generics tonite.

Regarding the need of a builder for each class, I think it would help
habing a consistent system across all the SCs.

Otherwise, this idea should apply to the other schema objects.


Le dim. 19 mars 2017 à 10:58, Stefan Seelmann  a
écrit :

> On 03/17/2017 11:00 AM, Emmanuel Lécharny wrote:
> > The only requirement is that each SC has its own builder (we can't put
> > this code in the abstract SC, because it's abstract...)
>
> With some generics magic it should at least be possible to move common
> stuff (setOid) to the parent.
>
> Otherwise, I'm not sure if it's worth to create builders for all the
> "simple" syntax checkers (Boolean, DirectoryString, etc.) or if just a
> singleton immutable instance is sufficient.
>
> But in general it makes sense to have immutable syntax checkers :)
>
>
> --
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

LDAP API 1.0-RC2 release coming soon

[Emmanuel Lecharny]

Hi guys,

I have started working n cutting a release for LDAP API.

There is not much I want to do for this release, which is quite importat
because it depends on MINA 2.0.15, which contains a critical SSL fix.

Otherwise, here are some JIRAs I want to address for this release :

* DIRAPI-259 : work in progress. We won't add some new controls in this
version
* DIRAPI-279 : this as to be fixed, and it's pretty trivial
* DIRAPI-237 : to be investigated
* DIRAPI-149 : a status is needed for this issue
* DIRAPI-207 : I'd like to get this fixed

I don't think we need days to get those fixed, and I hope it's going to
rain a lot this week-end to give me some time to work on that :-)




-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

LDAPConnection fixes

[Emmanuel Lecharny]

Hi !

Stefan has added some TODO in the LdapConnection interface :

// TODO: all the SASL bind methods are not declared in this interface, but
implemented in LdapNetworkConnection. Is that intended?
// TODO: why does connect() return a boolean? What is the difference
between false and an Exception?
// TODO: think about usage of abbrevisions (Dn/Rdn) vs. spelled out
(relative distinguished name) in javadoc
// TODO: describe better which type of LdapException are thrown in which
case?
// TODO: remove the "we" language in javadoc
// TODO: does method getCodecService() belong into the interface? It
returns a LdapApiService, should it be renamed?
// TODO: does method doesFutureExistFor() belong into the interface? Move
to LdapAsyncConnection?

I have fixed some of them :
- Replaced teh Dn/Rdn abbreviations by the full name
- Removed the 'we' all over the javadoc
- Replaced the doesFutureExistFor() method by a more explicit
isRequestCompleted() method. It's not a pure async method, it's also useful
when one want to abandon a request that takes too long.
- The connect() method returns a boolean to be able to distinguish between
a problem while establishing a connection, and a simple timeout because teh
remote host does not answer. We do have a retry mechanism in this case, and
when we reach the number of possible retries, we simply return 'false'. Of
course, when we have some more problematic problem, an exception is thrown.

Regarding the few oher TODOs :

- We have to add those SASL methods
- LDAPException : yes, it would be useful to list specific excpetions
instead of generic ones
- getCodecService() : this is a problem. the LdapApiService means nothing
for those who haven't wrote the API? CodecService is slightly more
significant. This method returns the container that exposes the supported
codec and extended operation. Renaming it to getServerFeatures() would be
better, but we should also rename the LdapApiService (something like
ServerFeatures would probably be clearer ?)

Thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ANNOUNCE] Apache Directory LDAP API 1.0.0-RC1 released

[Emmanuel Lecharny]

The Apache Directory Team is proud to announce the availability of version
1.0.0-RC1 of the Apache Directory LDAP API.

The Apache Directory LDAP API is an ongoing effort to provide an enhanced
LDAP API, as a replacement for JNDI and the existing LDAP API (jLdap and
Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server, but
should work pristine with any LDAP server.

It's also an extensible API : new Controls, schema elements and network
layer could be added or used in the near future. It's also OSGi capable.
The proposed release is a first step toward a GA, we have fixed numerous
issues that were pending.

Here is the list of fixed issues and added features :


Bugs :
--

  - DIRAPI-243 
 -
Cannot get AttributeType from Attribute
  - DIRAPI-244 
 -
Error in loading schema
  - DIRAPI-249 
 -
Performance issue LDAP API 1.0.0-M31
  - DIRAPI-265 
 -
Deserialized Dn loses bytes field resulting in null dn, treated as
Root DSE when encoded in ModifyRequests
  - DIRAPI-266 
 -
ResultCodeEnum 'NO_SUCH_OBJECT' should have message 'noSuchObject'
  - DIRAPI-273 
 -
api-ldap-net-mina bundle remains in STARTING mode
  - DIRAPI-274 
 -
The AttributeTypeHolder.toLdif method does not convert the m-usage
Attribute correctly
  - DIRAPI-275 
 -
Many AttributeType are defined with the wrong m-usage
  - DIRAPI-280 
 -
The LdapNetworkConnection.getTimeout() method is wrong


*Improvements :*

  - DIRAPI-282 
 -
Detection of timeout in cursor.next()


*New Features :*

  - DIRAPI-269 
 -
Add support for modular crypt format password


*Tasks :*

  - DIRAPI-270 
 -
Remove the dependency on commons.io


Website : http://directory.apache.org/api
Download : http://directory.apache.org/api/downloads.html
User's Guide : http://directory.apache.org/api/user-guide.html



-- 
Regards,
Cordialement,
Emmanuel Lécharnywww.iktek.com

Re: startTLS hostname verification

[Emmanuel Lecharny]

On 1/20/12 9:14 PM, Daniel Fisher wrote:

Looking over the API I don't see an obvious way to perform hostname
verification after the SSL handshake. Is this currently possible?


I have to  check that. It should be possible, as it's a part of the 
underlying MINA layer, but we may not expose this feature.


Can you feel a JIRA with your request so that it does not get buried in 
the stack of forgotten 'todo' tasks ?


Thanks !


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[ANNOUNCE] Apache LDAP API 1.0.0-M3 has been released !

[Emmanuel Lecharny]

The Apache Directory team is proud to announce the availability of the 
1.0.0-M3 version of the Apache Directory LDAP API.


The Apache LDAP client API is an ongoingeffort to provide an enhanced 
LDAP API, as a replacement for JNDI and the existing LDAP API (jLdap and 
Mozilla LDAP API).


This is a schema aware API, with some convenient ways to access a LDAP 
server. This API is not only targetting the Apache Directory Server, but 
should work pristine with any LDAP server.


It's also an extensible API : new Controls, schema elements and network 
layer could be added or used in the near future. *It includes an OSGi 
based plugin framework for extending the API.*


This is the first official milestone (two others have already been 
released but not announced), we will release few more milestone versions 
before a release candidate,  but the current version has already been 
validated in Directory Studio and in the Apache Directory Server. Its 
documentation is currently under construction.


Feel free to experiment, we highly appreciate your feedback !

Web site : http://directory.apache.org/api/
Download : http://directory.apache.org/api/downloads.html
User Guide : http://directory.apache.org/api/user-guide.html

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: LdapConnection threadsafe?

[Emmanuel Lecharny]

On 4/11/11 8:26 AM, Luis Pérez wrote:

Hi,

Is the LdapConnection object threadsafe?
It's supposed to be. You should be able to send a SearchRequest and an 
AbandonRequest through the same connection, and see your searchRequest 
abandonned (if it's a long one, of course.



Can I perform two concurrent
searches on the same LdapConnection?
Yes. But I must admit we never tested this case. We will add some test, 
that's a very valid question. I'll be back to you later today when I 
have tested this point.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [Shared] API Design Questionnaire #1

[Emmanuel Lecharny]

On 1/30/11 7:07 PM, Alex Karasulu wrote:

On Sun, Jan 30, 2011 at 7:29 PM, Stefan Seelmannseelm...@apache.orgwrote:


On Sun, Jan 30, 2011 at 5:11 PM, Alex Karasuluakaras...@apache.org
wrote:

On Sun, Jan 30, 2011 at 3:17 AM, Emmanuel Lecharnyelecha...@gmail.com
wrote:


On 1/29/11 10:38 PM, Stefan Seelmann wrote:


  [X] - (c)

interface = AddRequest
simple API exposed implementation =

AddRequest*Impl*

not so simple internal use implementation =
AddRequest*Decoder*
We're applying option 'C' right now. I'm torn but think A might suite

us

better for the long term, and for any situation. You also know what's

an

interface and what's not although the IDE automatically shows you this
stuff
on the package/class browser.


This is my opinion for a low-level API, which 1:1 maps LDAP
terminology to the Java API. I think we should additional have a
simplified API where the user don't need to deal with request and
response objects at all.

BTW: We have this discussion again and again ;-) We really need to
decide a consistent naming.


I think we already discussed it more than once, and we all agreed on

this

convention.

I'm not sure we want to rehash this again every 2 years :/



When there's a push to release a 1.0 of an API, we need to make the API
consistent. I can do this myself but the community way is to have a
discussion. If  you do not want to discuss this feel free not to
participate, or say you don't care.

I don't see that anyone said that the API development should not be
community driven.


I did not suggest anyone said that. If you read above I am saying I have no
choice but to post and share with the community rather than do it myself.


We have to be careful in our phrasing. Or we should be careful in the 
way we understand things.


The *I* notation in shared has been added temporarily in order to ease 
the refactoring, and should be removed in trunk.


Again, injecting them in trunk was probably a wrong move, and should 
have been done in a branch. We all know that...


Ok, assuming that this was just a misunderstanding, I guess we can move on.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Twitter for ApacheDS

[Emmanuel Lecharny]

 Hi !

just to inform you guys that we have created a twitter account 
(twitter.com/apacheDS) where we will put some relevant infos (well, we 
hope they will be relevant ;).


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

About operation result

[Emmanuel Lecharny]

 Hi,

long time, no see :)

I have a proposal about the way we handle the operation results. 
Currently, every operation is returning a Response, and if we want to 
know if the operation has been successful, we have to check the 
LdapResult field. This is not very convenient.


Assuming that when we have issued a synchronous operation, we are 
waiting until we get a response, why can't we have those operations 
throwing a LdapException ?


For async operations, we can also make that the XXXFuture.get() method 
throw the same exception.


thoughts ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Problems to do a search

[Emmanuel Lecharny]

On 5/12/10 1:07 PM, Juan Luis Hidalgo Vera wrote:

Hi,

We've found a problem when we do a search with a filter with * in 
the start or in the end of a expression with wildcards chars like for 
example filter (uid=*se*).


Sounds like a bug !

Can you open a JIRA for that ?

OTOH, you have to know that such a search will be very inefficient, as 
it will resolve to a full scan on the base. Note that it's not a 
workaround, just an information :)



--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: Immutable objects, what's best ?

[Emmanuel Lecharny]

On 3/14/10 9:46 AM, Stefan Seelmann wrote:

Emmanuel Lecharny schrieb:
   

Hi,

we have many objects that we want to be immutable. What's the best solution
to produce  those immutable objets ?

- For DN, we would like to use valueOf(), and the DN() constructor, but no
setter
- For Entry, a constructor is not enough, as we may have to inject new
attributes. We may need to have two different classes, one immutable, one
mutable. The immutable class could be associated with a factory, or we can
use a constructor with the list of attributes as a parameter.
- For attributes, we have the same problem : we may have more than one
value.

DO any of you guys have a strong opinion ?
 

Entry and Attribute object created by the user of the API shouldn't be
immutable. As user of the API I want to create an Entry object and add
attribute and values to it. So the API must provide setters.
   
I came to the same conclusion, but with another idea : create two Entry 
objects, one for the client, one for the server. It's close to what we 
have on ADS, but the more I think about it, the more I find it complex 
and bothersome.
Now, let's think about another option : what if we add a parameter in 
the constructor to create Immutable Entries ? Something like :
Entry immutableEntry = new EntryImpl( DN, true ); // True = the entry 
is immutable ?



So I think if Entry and Attribute are interfaces we just define the
getter methods.
   
Smart ! That could do the trick, sure ! But is it better than the 
previous solution?


My idea was to forbid a setter to be called if the Immutable flag is 
set, a solution I find a bit more strong than hiding the setter though 
the interface, but it forces the user to add a flag to the constructor.


Again, what do you think is the best approach ?

The default implementations of those classes (e.g. ClientEntry and
ClientAttribute) additional have setters the user can use when
constructing the objects.

The Entry objects returned from the API (e.g. from a search) should be
immutable to protect them from being casted by the user, e.g. by
wrapping a created ClientEntry into an ImmutableEntry implementation.
   
Hmmm... Do you suggest that we should define 2 different classes ? (one 
immutable, one mutable). Wouldn't it be better to have one single 
implementation, with a limited interface, forcing the user to cast to be 
able to use the setters ? Or should we have a ClientEntry class 
extending a ServerEntry class ?



--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: About exceptions

[Emmanuel Lecharny]

On 3/14/10 10:56 AM, Kiran Ayyagari wrote:


from the recent experience of migrating test cases to client-api
have observed that unlike jndi we return result codes and I liked this
(the jndi exceptions rather give me a feeling like 'use exceptions for 
control flow', which is considered as a bad practice by many)


so +1 for returning result codes instead of exceptions

Yes, that's pretty obvious we should do that.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Immutable objects, what's best ?

[Emmanuel Lecharny]

Hi,

we have many objects that we want to be immutable. What's the best solution
to produce  those immutable objets ?

- For DN, we would like to use valueOf(), and the DN() constructor, but no
setter
- For Entry, a constructor is not enough, as we may have to inject new
attributes. We may need to have two different classes, one immutable, one
mutable. The immutable class could be associated with a factory, or we can
use a constructor with the list of attributes as a parameter.
- For attributes, we have the same problem : we may have more than one
value.

DO any of you guys have a strong opinion ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

About exceptions

[Emmanuel Lecharny]

Hi,

it's about time to talk about exceptions, as many methods will throw an 
exception, and it would be good to know what to throw !


We should first have a base exception, and I suggest using 
LdapException. Evey other exception will inherit this one.


The second point is that the LDAP protocol define a list of errors, and 
we should map an exception to those errors. This has been done for JNDI, 
and it's a pretty good idea to keep our exception hierarchy close to the 
JNDI one.


AFAICT, neither OpenDS nor Unboundid define an exception hierarchy. 
Something I don't find useful is a method throwing a 
NullPointerException (IMO, this is totally useless, and certainly not an 
exception you want to add in the list of thrown exceptions for a method 
...).


jLDAP defines a few exceptions, with a base LDAPException class.
LDAPReferralException, LDAPLocalException are subclasses and used for 
some specific needs.



All in all, JNDI's exception system is pretty decent, and I think we 
should mimic it, but without implementing or extending the JNDI classes 
(something ADS is doing, and it collides with the renaming of DN, as 
it's not anymore a NAME extension).

thoughts ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Handling M$ specification violations

[Emmanuel Lecharny]

Hi,

M$, as usual, is violating many LDAP RFCs. For instance, you can send a 
simple BindRequest where the user name is *not* a DN.


I guess we will have to bend the API to accept such crapity...

wdyt ?

curseM$/curse

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Entry API

[Emmanuel Lecharny]

Hi,

here are some preliminary thoughts about the Entry class.

The Entry class
---

It's the base data structure representing an element stored into a LDAP 
server. It has a name (a DN) and some attributes.


All the existing API use the same name, Entry (or LDAPEntry), except 
JNDI which has no such class (it uses Attributes but without a DN) and 
this class contains at least those two inner elements :

- a DN
- a set of Attribute

There is some difference though as this element is either an Interface 
(ADS, ODS) or a Class (UID, jLdap)


ODS define an implementing class named SortedEntry, which does not make 
a lot of sense, IMO. ADS class hierarchy is even more complex, as there 
are two lower interfaces (ClientEntry and ServerEntry) with two 
implementing classes (DefaultClientEntry and DefaultServerEntry). 
Overkilling … (and will be rewritten soon)


All in all, I'm wondering if it's a good idea to have an interface 
instead of a class, as it does not make a lot of sense to implement some 
different version of such an object.


Constructors


Here are the current implementations :

ADS :
DefaultClientEntry()
DefaultClientEntry(LdapDN)
DefaultClientEntry(LdapDN, EntryAttribute...)
DefaultClientEntry(LdapDN, String...)
DefaultServerEntry(SchemaManager)
DefaultServerEntry(SchemaManager, Entry)
DefaultServerEntry(SchemaManager, LdapDN)
DefaultServerEntry(SchemaManager, LdapDN, AttributeType, String)
DefaultServerEntry(SchemaManager, LdapDN, AttributeType...)
DefaultServerEntry(SchemaManager, LdapDN, ServerAttribute...)
DefaultServerEntry(SchemaManager, LdapDN, String...)

jLdap :
LDAPEntry()
LDAPEntry(String)
LDAPEntry(String, LDAPAttributeSet)

JNDI :
N/A

OpenDS :
SortedEntry()
SortedEntry(DN)
SortedEntry(Entry)
SortedEntry(String)
SortedEntry(String...)

UID :
Entry(DN)
Entry(DN, Attribute...)
Entry(DN, CollectionAttribute)
Entry(String)
Entry(String, Attribute...)
Entry(String, CollectionAttribute)
Entry(String...)


Quite complex :/ The problem here is that we would like those entries to 
be schema aware. The question is : how to make it simple for the user to 
create a schema aware entry? Either the entry comes from the server he 
is connected to, or he creates new entries on the client before sending 
them to the server. In both cases, the entry has to know about the schema.


Let's first assume that it's the case. The minimal list of constructors is :
Entry() : an empty constructor
Entry(DN)
Entry(String) : The DN is a string
Entry(DN, Attribute…)
Entry(String, Attribute…)
Entry(String…) : A special constructor which takes a list of strings 
representing a LDIF form of the entry


All those constructors will assume that the default schema will be used.

We can then inject a Schema by adding it to the constructor :
Entry(SchemaManager) : an empty constructor
Entry(SchemaManager, DN)
Entry(SchemaManager, String) : The DN is a string
Entry(SchemaManager, DN, Attribute…)
Entry(SchemaManager, String, Attribute…)
Entry(SchemaManager, String…) : A special constructor which takes a list 
of strings representing a LDIF form of the entry


Thoughts ?

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Control wiki page

[Emmanuel Lecharny]

Hi,

I have added this page on the wiki :
http://cwiki.apache.org/confluence/display/DIRAPI/Control

--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: About the Control interface

[Emmanuel Lecharny]

Matthew Swift a écrit :

snip/
   GenericControl(String oid) // non-critical, null value
   GenericControl(String oid, boolean isCritical) // null value
Makes sense to add this constructor, but for Control with *no* value 
(semantically more accurate, compared to *null* value).

   GenericControl(String oid, boolean isCritical, ByteString bytes)

byte[] fits well, I think.

snip/


The Control API must distinguish between null values (i.e. value not 
present) and empty values (i.e. value present but zero-length).

Absolutely. I mis-judged this need, so we should add this method :

boolean hasValue();


I don't know if it is out of scope for now, but do we want to support 
extensibility? In particular, how can client applications implement 
their own controls? There are two main issues here that I have 
encountered:


  1. Decoding of response controls: if I have a response control whose
 type is MyControl do I want the LDAP SDK to automatically decode
 it to this type? Or will the client application have to do it.
 Here's some pseudo code to illustrate my point:

  // Result contains a MyControl response control.
  Result result = connection.add(entry);

  // Option #1: Uses an internal map of Control implementation
 classes - OID + decoder
  MyControl control = result.getControl(MyControl.class);




  // Option #2: Uses an internal map of OID - decoder
  MyControl control = (MyControl) 
result.getControl(MyControl.OID);


  // Option #3: No internal map - client has to manually decode
  Control control = result.getControl(MyControl.OID);
  MyControl myControl = new MyControl(control);

 I prefer the first approach for simplicity but it requires a
 public API for registering Control implementations (as does option
 #2) or use introspection and require that all implementations
 provide an OID field and a constructor having a single Control
 argument. Option #3 is quite verbose for clients IMO.

 I think that it's safer if the request/response API decodes the
 Control each time rather than caching the decoded control. This
 will make it possible to support immutable request/responses.

 If it sounds like I getting ahead here, the point of this issue is
 that if we want to provide an simple decoding mechanism like #1
 then we will need to have some way for the SDK to be able to
 decode the Control. This means either having a registration
 process, or using introspection and having a well defined
 constructor and OID field.

 The same problem will present itself for the following API features:

 * decoding extended responses

 * decoding intermediate responses

 * decoding request controls (server-side so out of scope)

 * decoding extended requests (server-side so out of scope)

  2. Encoding/decoding controls: many control values are encoded using
 ASN1. Do we want to provided ASN1 support? This will also apply
 for new extended operations.

I think that these questions are only applicable if we decide to 
support extensibility.
Well, IMO, from the client side, these issues can occur only if the 
provided API does not support some of the server's Controls. In this 
case, the user will have to create his own Control, implementing the 
Control interface, and do the decoding himself. What the API will 
generate is a instance of Control where the ID, criticality and value 
are stored as opaque elements - especially for the value -. Up to the 
user to translate this instance to its own control.


I'm not sure that providing anything more complex ATM is usefull. Who 
develops Controls, anyway ?



--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: [DN] Existing API review

[Emmanuel Lecharny]

Matthew Swift a écrit :




public DN(String dnStr) {
 return valueOf( dnStr );
}


Nothing will prevent you from writing something like that, but the 
compiler will prevent you from compiling it. Get some sleep! ;-)

Doh !!! Yeah, or maybe some stronger coffee ;)


--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com