It would kind of cool if the Web Console could pass its username and password through to JMS. This assumes of course that Web Console has been setup with BASIC auth. But that is a fair assumption, because if your destinations are password protected, your webconsole is likely also protected.
I actually played around a bit with having Jetty use ActiveMQ's JAAS plugin. I never finished testing it, but it should work. In this case, everything should just work, and there would be unified auth for all of the protocols. Of course, JMX is always an option, instead of JMS. If the Web Console queueBrowser used JMX, it would work just fine. I can browse the queue fine with JConsole, so I know JMX works. And since everything that Web Console uses is otherwise JMX, this kind of makes sense (at least it would be consistent). I guess it would also be a good idea to document that a JMX read-only user can read any destination. And a JMX write user can write to any destination. So JMX auth trumps ActiveMQ destination auth. Which is fair, since an JMX user can shut the JVM down too. I guess the ActiveMQ.Agent is more thorny. I don't really understand this issue. ActiveMQ.Agent is an internal topic, like the advisory topics, so why is ActiveMQ crashing on start when destination security is defined? Is this even worth fixing? If the Web Console had a page that showed queue subscribers, I don't think you'd need both. Maybe just leave the ActiveMQ.Agent disabled by default. I'd prefer one 100% working interface, rather than two partially broken interfaces. ----- "Mario Siegenthaler" <[EMAIL PROTECTED]> wrote: > Hi > Tom pointed out the problem with the web console and a secured > JMS-connection. While it's already possible to configure that over > JNDI and straightforward to make that configurable via > system-properties, this will be an issue for the in-vm jetty, that's > started with the broker. We'd require the user to set a user/password > to connect to the invm-broker. IMO this is quite a hassle (the same > thing is true for the console, this thing in fact kills the broker > because it can't startup because it gets a invalid username/password > exception). > The easiest thing'd be to allow vm:// connections without checking > for > username/password. The problem with this approach is certainly that > the policy check on the queues/topics'd have to be ignored. > > Any thoughts on this topic? I'll be happy to write a patch as soon as > I know the way we want to go. > > Mario
