[
https://issues.apache.org/activemq/browse/AMQ-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Snyder closed AMQ-1049.
-----------------------------
Resolution: Cannot Reproduce
Fix Version/s: (was: AGING_TO_DIE)
> 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.0.1, 4.1.0
> 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.
-
You can reply to this email to add a comment to the issue online.
