activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Hofstaedter (JIRA)" <>
Subject [jira] Created: (AMQ-1049) SimpleAuthenticationBroker and AbstractConnection allow messages from a Producer that fails logon
Date Tue, 14 Nov 2006 21:28:02 GMT
SimpleAuthenticationBroker and AbstractConnection allow messages from a Producer that fails

                 Key: AMQ-1049
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 4.1.0, 4.0.1
         Environment: The OS is Windows XP.  The producer is running in one JVM loaded via
JNI invokation with an embedded broker and a DemandForwardingBridge that 
is connecting to the remote broker via "tcp://".  The consumer and the BrokerService
are running on the same machine but in another JVM also loaded via JNI invokation but communicating
with each other via "vm://localhost".
            Reporter: Chris Hofstaedter

I was trying to set up a SimpleAuthenticationBroker programatically rather than through the
xml.  I've tried with 4.0.1 and 4.1.  The symptom was that, although the broker is set as
an intercepter and it detects a bad password and emits a SecurityException, the producer is
still allowed to produce messages.  I can see the producer get the bad login indication through
the following log message: 

WARN - Unexpected remote command: ConnectionError
{commandId = 2, responseRequired = false, connectionId = null, exception = java.lang.SecurityException:
User name or password is invalid.}

But then, the next thing I know, my consumers, that have successfully logged in, start receiving
messages from this very same producer.

After some investigation, I've been able to get the behavior I want, but I had to modify
to do it.  I dont know if my modifications are appropriate, so could someone take a look and
let me know whether this is a desirable change or not?

Specifically, I added an additional catch block after line 202 of AbstractConnection and before
the catch(Throwable).  The new code is: 

catch ( SecurityException e1)
   ConnectionError ce = new ConnectionError();
   catch (Exception e2)
      serviceLog.error("Unable to stop the connection after the SecurityException:  " + e2);

Notice the dispatchSync versus dispatchAsync - I did this to ensure that the client was informed
off the security violation before the connection is stopped.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message