You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Tom Samplonius <to...@samplonius.org> on 2007/06/21 02:57:40 UTC
Actually getting Stomp support to a usable state...
----- "James Strachan" <ja...@gmail.com> wrote:
...
> Just use the JAAS plugin in ActiveMQ and you're good to go; the Stomp
> code uses whatever security plugin you're using
As has been discussed, this is broken, and has been since 4.1.1 or earlier.
Is there any sort of roadmap to the ActiveMQ internals, so I can take a stab at fixing this without having to start from scratch? All of the wire protocols tie back to some sort of core, where auth is evaluated. And that is supposed to flow back to the wire protocol again.
And the ActiveMQ core just depends on the protocol to do the right thing. If the auth failed, it will still take successive commands.
...
> I know lots of folks using both the Web Console and Stomp in
> production with security
But I don't know how this could be possible, unless people just haven't tried with a mis-spelled password. And there isn't a release version of ActiveMQ that doesn't lose Stomp messages one way or another. So I have to assume that they production sites are using snapshots too.
But Stomp support is as buggy as hell in ActiveMQ. It seems that the ActiveMQ project operates in some sort of twilight mode. Most projects would have issued a security advisory. Doesn't the Apache Foundation require its projects to issue security advisories for serious security problems? Doesn't the "Apache Way" include, "security as a mandatory feature"?
If no one can fix Stomp, that's fine, but it should be at least be disabled on default configuration.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
Re: Actually getting Stomp support to a usable state...
Posted by PieterN <se...@internethoofdkantoor.nl>.
James.Strachan wrote:
>
>> All of the wire protocols tie back to some sort of core, where auth is
>> evaluated. And that is supposed to flow back to the wire protocol again.
>>
>> And the ActiveMQ core just depends on the protocol to do the right
>> thing. If the auth failed, it will still take successive commands.
>
> Yeah, that sounds an easy one to fix; we just need to disconnect the
> socket if a connection fails I guess? Fancy taking a stab at it? Am
> thinking some code in ProtcolConverter if an exception occurs on the
> response, to just close the connection (after the ERROR is sent back).
>
This is more or less what my patch does posted elsewhere in this thread.
It's a bit of a hack however, it doesn't send an error frame. This is (I
think) because the connection isn't set up properly, the function just bails
out. A proper solution (which sends an ERROR frame) probably requires a bit
of rewriting of the onStompConnect method.
BTW, Tom reported in this thread this patch didn't work for him. I have no
idea why, it did for me. It is against a 4.2 snapshot from ~ 1 month old I
think. I think it doesn't work for 4.1, I believe there were some changes
after that upstream in the code flow to actually throw the Exception.
This is the patch I was talking about:
---
src/activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
2007-05-11 02:02:04.000000000 +0200
+++
src/activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
2007-05-22 12:41:32.000000000 +0200
@@ -36,6 +36,7 @@
import org.apache.activemq.command.ConnectionInfo;
import org.apache.activemq.command.ConsumerId;
import org.apache.activemq.command.ConsumerInfo;
+import org.apache.activemq.command.ExceptionResponse;
import org.apache.activemq.command.LocalTransactionId;
import org.apache.activemq.command.MessageAck;
import org.apache.activemq.command.MessageDispatch;
@@ -413,7 +414,18 @@
connectionInfo.setPassword(passcode);
sendToActiveMQ(connectionInfo, new ResponseHandler(){
- public void onResponse(ProtocolConverter converter, Response response)
throws IOException {
+ public void onResponse(ProtocolConverter converter, Response response)
throws IOException, ProtocolException {
+
+ /* PN: if the response is an exception, propagate the exception to send
an ERROR frame */
+ if (response.isException()) {
+ ExceptionResponse exception = (ExceptionResponse) response;
+ // apparently, other (non-fatal) exceptions are generated as well (see
debug log)
+ if (exception.getException() instanceof SecurityException) {
+ // FIXME: should set up connection, send an ERROR frame, and
disconnect
+ // this disconnects immediately
+ throw new ProtocolException(exception.getException().getMessage());
+ }
+ }
final SessionInfo sessionInfo = new SessionInfo(sessionId);
sendToActiveMQ(sessionInfo,null);
Hope this helps.
Regards,
Pieter Naaijkens
--
View this message in context: http://www.nabble.com/Getting-Stomp-support-to-a-usable-state...-tf3858629s2354.html#a11248423
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Actually getting Stomp support to a usable state...
Posted by James Strachan <ja...@gmail.com>.
On 6/21/07, Tom Samplonius <to...@samplonius.org> wrote:
>
> ----- "James Strachan" <ja...@gmail.com> wrote:
> ...
> > Just use the JAAS plugin in ActiveMQ and you're good to go; the Stomp
> > code uses whatever security plugin you're using
>
>
> As has been discussed, this is broken, and has been since 4.1.1 or earlier.
>
> Is there any sort of roadmap to the ActiveMQ internals,
We use JIRA for the roadmap...
http://issues.apache.org/activemq/browse/AMQ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> so I can take a stab at fixing this without having to start from scratch?
Awesome! We *love* contributions....
http://activemq.apache.org/contributing.html
> All of the wire protocols tie back to some sort of core, where auth is evaluated. And that is supposed to flow back to the wire protocol again.
>
> And the ActiveMQ core just depends on the protocol to do the right thing. If the auth failed, it will still take successive commands.
Yeah, that sounds an easy one to fix; we just need to disconnect the
socket if a connection fails I guess? Fancy taking a stab at it? Am
thinking some code in ProtcolConverter if an exception occurs on the
response, to just close the connection (after the ERROR is sent back).
> > I know lots of folks using both the Web Console and Stomp in
> > production with security
>
> But I don't know how this could be possible, unless people just haven't tried with a mis-spelled password. And there isn't a release version of ActiveMQ that doesn't lose Stomp messages one way or another. So I have to assume that they production sites are using snapshots too.
Which message loss thing is that? Is there a JIRA?
> But Stomp support is as buggy as hell in ActiveMQ.
Thats a little strong, AFAIK there's only a couple of bugs...
> It seems that the ActiveMQ project operates in some sort of twilight mode. Most projects would have issued a security advisory. Doesn't the Apache Foundation require its projects to issue security advisories for serious security problems? Doesn't the "Apache Way" include, "security as a mandatory feature"?
FWIW most JMS providers come with no security at all out of the box;
as MOMs are typically run inside the firewall & security is usually
enabled by changing the default configuration.
But you are right, we should log a warning that security in STOMP does
not work properly, so a mis-behaving stomp client could actually do
bad things.
> If no one can fix Stomp, that's fine, but it should be at least be disabled on default configuration.
We may as well fix this bug before the next release, rather than doing
a release just to disable stomp support
--
James
-------
http://macstrac.blogspot.com/