You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by dabayev <da...@fortress.com> on 2016/07/12 20:37:06 UTC

Read-only user functionality

Hi,

I have a scenario, where I would like to have a read-only user setup on my
queue, which can read the queue or browse the queue, but not able to consume
the messages

The current authorizationEntry tag, has three levels of security control
(read - consume the message, write - produce the message, admin - do
whatever you want). I am looking for readonly control where the user in the
group can view the message via JMS API using selectors and etc, but not
consume the message.

I know QueueBrowser can achieve that, but in order for me to open a
connection to activemq I need to pass user/password and that user has to
have at least read access to the queue I am trying to browse. That meas the
same connection will have access to consume message from the queue, which i
need to avoid.

I also looked at doing this via URL like this
http://localhost:8161/admin/queueBrowse/MY.QUEUE?msgId=123324234. This
works, but the only shortfall is that the <content><data> and
<marshalledProperties><data> are encrypted and I have no clue on how to
decrypt that.

Can you please point me to a solution where I can have a true read only
browser without exposing risk of message consumption.

Thank you



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by Dan Abayev <da...@fortress.com>.
Thank you for your explanation Tim.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714309.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by Tim Bain <tb...@alumni.duke.edu>.
The community as a whole is not focusing exclusively on Artemis.  Some
people work on Artemis, some people work in 5.x.  Many people hope and
expect that at some point, Artemis will take over as ActiveMQ 6.x (whether
it's called that or not), and the 5.x codebase would then be left behind,
but it's not a given that it will happen and even assuming it does, there's
no explicit timeframe for the transition.  Until that point, 5.x remains
under active development and support.

From what I've seen, the Artemis developers are generally very quick about
responding to posts on the mailing list, and seem to implement fixes
quickly when those posts result in a bug report.  (Kudos.)

5.x posts are also responded to, but more of them go unanswered (because
those of us who monitor the list don't always know everything about all
topics) and there is sometimes a longer delay before a response.  Those
things are partly due to who's available to monitor the list (and how much
time we can donate to that effort) and partly due to the fact that there
are currently far more 5.x questions than Artemis questions.  5.x bugs are
fixed (you can look at the release notes of the just-released 5.13.4
incidental version for a sense of how much goes into a dot drop, and you
can look at the release notes for a 5.x.0 release for a sense of how many
things are fixed in a minor version), and as you'd probably expect, the
ones that are better-written and/or hit a more-useful or
more-broadly-applicable issue generally get implemented faster than
poorly-written ones that add little value in niche use cases.  And for both
5.x and Artemis, your odds of a fix getting implemented quickly go up
substantially if you implement and submit the fix yourself along with the
JIRA bug.  We're both open-source projects, and we gladly accept
contributions, though bugs will still get fixed even if the respective
developers have to implement the fix themselves.

Tim

On Mon, Jul 18, 2016 at 3:20 PM, Dan Abayev <da...@fortress.com> wrote:

> Thanks for the explanation. I will have to convince my architect to let me
> do
> that with an open source project. Too many restrictions.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714058.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Re: Read-only user functionality

Posted by Dan Abayev <da...@fortress.com>.
Thanks for the explanation. I will have to convince my architect to let me do
that with an open source project. Too many restrictions.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714058.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by Justin Bertram <jb...@apache.com>.
Your position is understandable.

A PR is a "pull request." It's akin to a patch in the world of Git (i.e. the SCM used by Apache ActiveMQ).


Justin

----- Original Message -----
From: "dabayev" <da...@fortress.com>
To: users@activemq.apache.org
Sent: Monday, July 18, 2016 3:23:03 PM
Subject: Re: Read-only user functionality

Justin, the reason I won't be able to convert to Artimis is bureaucracy. I
will have to justify why we need to migrate to Artimis from 5.x. This would
include the costs of POC, development, QA and etc... If I tell my architect
it is solely for the BROWSE role, then he will throw it out and will tell me
to write a tool. There is no other functionality that we lack in 5.x at this
point. Hope that explains my position.

Also, what is a PR? Excuse my ignorance. 



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714056.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by dabayev <da...@fortress.com>.
Justin, the reason I won't be able to convert to Artimis is bureaucracy. I
will have to justify why we need to migrate to Artimis from 5.x. This would
include the costs of POC, development, QA and etc... If I tell my architect
it is solely for the BROWSE role, then he will throw it out and will tell me
to write a tool. There is no other functionality that we lack in 5.x at this
point. Hope that explains my position.

Also, what is a PR? Excuse my ignorance. 



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714056.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by Justin Bertram <jb...@apache.com>.
I can't really speak for the community. I can only speak for myself. Personally, I am interested in Artemis and therefore focus my work there.

As for https://issues.apache.org/jira/browse/AMQ-6364 which you opened against 5.x I can only recommend you submit a PR for the functionality yourself or wait and see who might do the work for you. There are certainly still many active 5.x users and contributors so someone might pick it up.

Aside from that, I'm curious what your risk would be in migrating to Artemis from 5.x. Can you elaborate on that?


Justin

----- Original Message -----
From: "dabayev" <da...@fortress.com>
To: users@activemq.apache.org
Sent: Monday, July 18, 2016 1:23:47 PM
Subject: Re: Read-only user functionality

Hi Justin,

Thank you for your response, I actually now understand what Artemis is and
where it came from.
Based on information in a couple of threads that I have read, I wont be able
to migrate from 5.x to Artemis  without taking on risk, and that is a
blocker. 

I do have a question though. I see that the JIRA you posted was is fairly
new, only a week old and resolved right away. I want to get a sense of
product development focus between 5.x and Artemis. If the same JIRA was to
be created under 5.x, would it be fairly quickly resolved and released in
next 5.x version? Or is the community focusing on Artemis exclusively?

Thank you again for shedding some light on this.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714052.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by dabayev <da...@fortress.com>.
Hi Justin,

Thank you for your response, I actually now understand what Artemis is and
where it came from.
Based on information in a couple of threads that I have read, I wont be able
to migrate from 5.x to Artemis  without taking on risk, and that is a
blocker. 

I do have a question though. I see that the JIRA you posted was is fairly
new, only a week old and resolved right away. I want to get a sense of
product development focus between 5.x and Artemis. If the same JIRA was to
be created under 5.x, would it be fairly quickly resolved and released in
next 5.x version? Or is the community focusing on Artemis exclusively?

Thank you again for shedding some light on this.



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714052.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by Justin Bertram <jb...@apache.com>.
I don't know of a way to achieve this with ActiveMQ 5.x (but then again I'm no expert on 5.x).  However, I think you can achieve what you want using the latest snapshot of ActiveMQ Artemis as a BROWSE permission was recently added via https://issues.apache.org/jira/browse/ARTEMIS-628.


Justin

----- Original Message -----
From: "dabayev" <da...@fortress.com>
To: users@activemq.apache.org
Sent: Monday, July 18, 2016 11:11:57 AM
Subject: Re: Read-only user functionality

Can someone please help with this?



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714049.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Read-only user functionality

Posted by dabayev <da...@fortress.com>.
Can someone please help with this?



--
View this message in context: http://activemq.2283324.n4.nabble.com/Read-only-user-functionality-tp4713881p4714049.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.