On 4/15/11 9:01 AM, Pierre-Arnaud Marcelot wrote:
Hi Emmanuel,
AFAIR (I'm the one who created those three classes and their abstract
superclass) the idea was to be able to store all the client parameters (login,
password, various SASL settings) in simple classes. These classes being used
with an LDAP Connection via a bind request.
It was a good thing, but in fact the Java Sasl implementation already
stores those values, AFAICT.
I'll have to look in the code, but I think that we've used the SaslClient class
internally to manage the challenge/response dialog, ie. we haven't (hopefully)
reimplemented everything.
Have a look at the LdapNetworkConnection.bindSasl(...) method.
We do, but we should not have the DigestMd5Request, CramMD5Request and
GssApiRequest classes extending a SaslRequest containing the parameters
already present in the SaslClient classes, that's what I'm currently
thinking.
To me, the basic idea was that the casual LDAP user should not know about the
SASL implementation and/or the SaslClient classes.
Totally agree.Md5( ...)
He only uses our simple API classes to describes the LDAP bind requests (with
SASL) and lets the API do all the work without worrying about complex
encryption mechanisms, challenge/response, or having to learn another complex
API (the SaslClient API).
I have to dig further. I took the problem by the other side in fact :
- I wanted to create a SASL BindRequest, and I hit a wall fast. Maybe I
should have a look at the current LdapNetworkConnection code to see how
it works for the existing mechanism (MD5 and GSSAPI), instead of trying
to write the same thing for EXTERNAL and PLAIN from scratch...
Thanks for the enlighments, Pierre-Arnaud !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
