Hi Jan,
There are no *plans* as such - mainly due to limited time and the fact
that it hasn't been a priority for me (I'm trying to focus on getting a
JavaScript implementation of AMQP 1.0 sorted and get my head around AMQP
1.0 Management)
I agree that it's potentially useful. There is some fairly basic
authentication as you might have discovered, it literally uses
BasicAuthentication which has tended to be good enough for me as I only
tend to need to use it on a private network.
It's worth mentioning that you can configure the default connection
using any valid Java ConnectionURL and if you simply use the configured
default AMQP connection that info doesn't pass over the network to the
UI (in that case it just uses "" as the URL) so if you're only managing
a single broker it's not necessarily as insecure as you'd think given
just basic authentication (that's partly why I've never really had to do
more).
That doesn't help you with your read only/read/write users thing though.
I have toyed with "admin" and "normal" users, but I'm afraid I've never
got around to it. I'm guessing that you want to restrict read only users
to prevent them adding and deleting queues/exchanges.
As a nasty hack (sorry!) you might be able to fire up two instances of
the QpidRestAPI on different ports.
What you'd need to do is copy the qpid-web subdirectory, but in there in
"authentication/account.properties" is where the username and password
stuff is held. If you have one instance as "admin" and another say as
"user" you can specify the web root when you start up QpidRestAPI.
Now if you were to do that then you could specify different connection
URLs for each instance (with different Qpid usernames and passwords) and
then use Qpid's ACL mechanism to prevent adding and deleting queues etc.
from the "user" Connection.
As I say it is a bit of a nasty hack, but I think that it it technically
possible (I'm no expert on Qpid authentication and ACLs though) - and in
practice it might *actually* be what you'd want anyway (depending on
your level of paranoia) because even if the GUI were to have a mechanism
to do what you suggest someone could still add/delete stuff via
qpid-config or (if they were sufficiently knowledgeable) directly via
the QMF protocol. (and they could certainly at least add
queues/exchanges using a suitably constructed Address String).
Personally I'd just threaten to break their fingers if they messed with
my broker ;-D
I'm going to have to get stuck into it again when I look to try and do
something with AMQP 1.0 Management so I'll definitely give it some
thought, but I can't promise timescales at the moment I'm afraid.
Regards,
Frase
On 05/03/14 15:21, Jan Bares wrote:
Are there any plans to include authorizations too? For me, and I hope for other
users too, it would suffice to have read-only users and read/write (modify)
users.
Kind regards, Jan
-----Original Message-----
From: Gordon Sim [mailto:[email protected]]
Sent: Wednesday, March 05, 2014 12:10 PM
To: [email protected]
Subject: Re: QPID C++ broker monitoring and management
On 03/05/2014 09:55 AM, Jan Bares wrote:
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java
Thanks. I see there are some problems with Cygwin compatibility, where
can I post patches or suggestions?
You can use JIRA and or this list (there is a 'Java Tools' component in
JIRA). For patches a JIRA is best, but feel free to post an accompanying
email to this list as well.
Thanks in advance for any suggestions or improvements!
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
DISCLAIMER
________________________________
WOOD & Company Financial Services, a.s. and its branches are authorized and
regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS
and in the UK by the FCA as Host State regulators. For further information about WOOD &
Co., its investment services, financial instruments and associated risks, safeguard client
assets (incl. compensation schemes) and contractual relationship please see our website at
www.wood.com<http://www.wood.com/> under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the
solicitation of an offer to sell or purchase any investment. All estimates, opinions
and other information contained herein are subject to change without notice and are
provided in good faith but without legal responsibility or liability. Opinion may be
personal to the author and may not reflect the opinions of WOOD & Co.
Communications from sales persons, sales traders or traders should not be regarded as
investment research and may contain opinions or trading ideas which are different from
WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or
otherwise protected from disclosure. If you are not a named addressee you must not use,
disclose, distribute, copy, print or rely on this e-mail and any of its attachments.
Please notify the sender that you have received this email by mistake by replying to
the email, and then delete the email and any copies of it. Although WOOD & Co.
routinely screens e-mails for viruses, addressees should scan this e-mail and any
attachments for viruses. WOOD & Co. makes no representation or warranty as to the
absence of viruses in this e-mail or any attachments. Please note that to ensure
regulatory compliance and for the protection of our clients and business, we may
monitor and read e-mails sent to and from our server(s).
________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
