[ https://issues.apache.org/activemq/browse/AMQ-1049?page=comments#action_37481 ] Chris Hofstaedter commented on AMQ-1049: ----------------------------------------
I just tried this with the 4.0.2 release and the problem does not exist there. > SimpleAuthenticationBroker and AbstractConnection allow messages from a > Producer that fails logon > ------------------------------------------------------------------------------------------------- > > Key: AMQ-1049 > URL: https://issues.apache.org/activemq/browse/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://127.0.0.1:61616". 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 org.apache.activemq.network.DemandForwardingBridge - 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 AbstractConnection.java 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(); > ce.setException(e1); > dispatchSync(ce); > try > { > this.stop(); > } > 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: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
