activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <>
Subject [jira] Updated: (AMQ-1049) SimpleAuthenticationBroker and AbstractConnection allow messages from a Producer that fails logon
Date Mon, 08 Sep 2008 14:55:57 GMT


Gary Tully updated AMQ-1049:

    Fix Version/s: 5.3.0
                       (was: 5.2.0)

> SimpleAuthenticationBroker and AbstractConnection allow messages from a Producer that
fails logon
> -------------------------------------------------------------------------------------------------
>                 Key: AMQ-1049
>                 URL:
>             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://".  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
>             Fix For: 5.3.0
> 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();
>    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.

View raw message