Ok, so...
If you activate CODEC_LOG in DEBUG mod,e you'll have all the info about
the PDU decoding. This part:
if ( messageContainer.getState() == TLVStateEnum.PDU_DECODED )
{
if ( CODEC_LOG.isDebugEnabled() )
{
CODEC_LOG.debug( I18n.msg(
I18n.MSG_14002_DECODED_LDAP_MESSAGE, messageContainer.getMessage() )
}
Message message = messageContainer.getMessage();
decodedMessages.add( message );
messageContainer.clean();
}
will tell you if the PDU is correctly drafted, and you should get a
meesage like:
Decoded LdapMessage: blah
in the logs for every BindRequest (and all the other requests)
If you see the PDU, but not that message, that means the PDU is
incorrect, or that the decoding is flawed.
I'm still wanting to see the PDU, with redacted data from it.
Otherwise, when the BindRequest is decoded, it flows up to the
LdapRequestHandler which is directly plugged on top of MINA:
- at startup the BindRequestHandler is associated with the class
BindRequest (which is instanciated by the decoder)
- when a Bind Request is received, it's decoded and a BindRequest object
is created
- this instance is pushed up to the DemuxingIoHandler (a MINA class),
which select the proper handler to manage the incoming message
- last, not least, the BindRequestHandler is executed
So if the pb is not during the decoding part, then it's somewhere in
between the decoding and the handling. There is a lack of logs because
this part was never problematic since 2005, so my bet is that the
decoding is failing. It's not only a bet, though, because if it's not
that, then we are a bit naked to find out what could go wrong...
Otherwise, *if* the decodning is successful, if the BindRequest instance
is created, if it flows up to the ApacheDS handler, then it goes through
this function:
public void messageReceived( IoSession session, Object message )
throws Exception
{
if ( ( ( Request ) message ).getControls().size() > 0
&& message instanceof ResultResponseRequest )
{
// This is where we go if the request contains some controls
}
super.messageReceived( session, message );
}
It then calls this function:
public void messageReceived(IoSession session, Object message) throws
Exception {
MessageHandler<Object> handler =
findReceivedMessageHandler(message.getClass());
if (handler != null) {
handler.handleMessage(session, message);
} else {
throw new UnknownMessageTypeException("No message handler
found for message type: "
+ message.getClass().getSimpleName());
}
}
which calls the proper handler:
public void handle( LdapSession ldapSession, BindRequest
bindRequest ) throws Exception
{
LOG.debug( "Received: {}", bindRequest ); <<------- This is
the log you should see if teh decoding was successful
// Guard clause: LDAP version 3
if ( !bindRequest.getVersion3() )
{
// error -> get out
...
}
// Deal with the two kinds of authentication : Simple and SASL
if ( bindRequest.isSimple() )
{
handleSimpleAuth( ldapSession, bindRequest );
}
else
{
handleSaslAuth( ldapSession, bindRequest );
}
}
On 14/02/2024 02:19, Marc Boorshtein wrote:
so you see the PDU being processed on the server, AFAIU.
Yes
Do you get any log from the BindRequestHandler?
No, we enabled logging on BindRequestHandler and see logging for other
transactions, but not these
Is this a Sasl bind request?
No, simple bind
Any control in the BindRequest?
I don't believe so but will double check.
Could you provide the PDUs?
unfortunately, no. it only happens in production and the customer will
never let me share that.
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org