python client exchange/queue query issue

[Mark White <mw...@redhat.com>]

Hello, this is just a feeler to see if any sort of jira should be opened and against which client(s):

Background:
Connecting to a queue or exchange using the python 0.14 client library issues two calls: ExchangeQuery(name='obj_name', id=serial(0), sync=True) and QueueQuery(queue='obj_name', id=serial(1), sync=True).  This is true whether or not the connection has specified the node type.

Example queue connection: queueName; {create:always, delete:receiver, node: {type: queue, durable: True, x-declare: {alternate-exchange: 'exchangeName'}, x-bindings: [{exchange: 'exchangeName', queue: 'queueName', key: 'binding.key'}]}}

Changing the connection string for an exchange which node:{type:topic, x-declare: {type: <type>}} produces similar results (both queries are performed every time).

Issue:
Why are both ExchangeQuery and QueueQuery performed every time a sender or receiver is created, if the node type is declared in the connection string?

After speaking with some people, it sounds like the C++ client libraries are not doing the same thing, but that wasn't confirmed.  It's thought that the C++ client code only performs a lookup based on the node type if it's specified.  If that's the case, should the libraries be made to operate the same, and if so, should the python libraries change, or should the C++ libraries change?  I haven't looked at the JMS libraries yet, but the client I'm working with will be using JMS, so that will need to be addressed as well.


As a general note, the way I found this was by setting up ACL rules that limit users from querying for queues and exchanges they shouldn't have access to.  Because of the way the python code operates, I had to allow access to both the exchange and the queue of a common name, even though I knew, due to naming conventions, that it would only ever be a queue or an exchange, not both.

Example acl rules needed when using python client:
acl allow <groupName> access exchange name=queueName
acl allow <groupName> access queue name=queueName


Thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: python client exchange/queue query issue

[Gordon Sim <gs...@redhat.com>]

On 09/05/2012 11:47 PM, Mark White wrote:
> Hello, this is just a feeler to see if any sort of jira should be
> opened and against which client(s):
>
> Background: Connecting to a queue or exchange using the python 0.14
> client library issues two calls: ExchangeQuery(name='obj_name',
> id=serial(0), sync=True) and QueueQuery(queue='obj_name',
> id=serial(1), sync=True).  This is true whether or not the connection
> has specified the node type.
>
> Example queue connection: queueName; {create:always, delete:receiver,
> node: {type: queue, durable: True, x-declare: {alternate-exchange:
> 'exchangeName'}, x-bindings: [{exchange: 'exchangeName', queue:
> 'queueName', key: 'binding.key'}]}}
>
> Changing the connection string for an exchange which
> node:{type:topic, x-declare: {type: <type>}} produces similar results
> (both queries are performed every time).
>
> Issue: Why are both ExchangeQuery and QueueQuery performed every time
> a sender or receiver is created, if the node type is declared in the
> connection string?
>
> After speaking with some people, it sounds like the C++ client
> libraries are not doing the same thing, but that wasn't confirmed.

I can confirm they do not do the same thing.

If the node type is *not* specified, its type must be determined in 
order for senders/receivers to behave correctly. The c++ client does 
this using an ExchangeBound call to the broker. The response to that 
call indicates whether there is a queue with that name, or whether there 
is an exchange of that name or both.

If the node type *is* specified in the address string, the c++ client 
does not attempt to 'resolve' the node name in this manner.

Once the client determines what the node type is (either from the 
address string or by querying the broker), it then issues a 
QueueDeclare/ExchangeDeclare as appropriate (with the passive flag 
determined by the create option in the address).

> It's thought that the C++ client code only performs a lookup based on
> the node type if it's specified.

As above, it is actually the opposite. The c++ client only attempts to 
determine the type through a query if it is not explicitly specified in 
the address string.

> If that's the case, should the
> libraries be made to operate the same,

Yes, they should. I actually have a JIRA assigned for this already: 
https://issues.apache.org/jira/browse/QPID-3456, but I'm afraid I have 
not got around to tackling it.

> and if so, should the python
> libraries change, or should the C++ libraries change?  I haven't
> looked at the JMS libraries yet, but the client I'm working with will
> be using JMS, so that will need to be addressed as well.
>
>
> As a general note, the way I found this was by setting up ACL rules
> that limit users from querying for queues and exchanges they
> shouldn't have access to.  Because of the way the python code
> operates, I had to allow access to both the exchange and the queue of
> a common name, even though I knew, due to naming conventions, that it
> would only ever be a queue or an exchange, not both.

If the node type is specified, in my view you should not require 
permission to access both queue or exchange, but only whichever one is 
specified.

However if it is *not* specified then I think it is reasonable that the 
client requires permission to access both a queue and an exchange of 
that name.

You could argue that you should only require the permission if the 
queue/exchange exists. But that in itself allows unauthorised clients to 
'see' which queues exchanges exist.

Now, there is currently a quirk in the c++ broker - a bug in my view - 
that means the c++ client doesn't require both permissions when the type 
is not specified. The handling of exchange-bound only requires access 
permission for the exchange, even if a queue name is specified and checked.

So, my view, is that the python client should not have to query the 
broker for both the exchange/queue if the type is specified and the 
exchange-bound implementation on the broker should require queue access 
permission if a queue name is specified.

That would I think bring the two clients into closer alignment (and 
greater correctness in my view) with relatively small changes.

That isn't yet full alignment of course. However at present I believe 
that a 1.0 implementation of the messaging API is more important and so 
am pursuing that.

Thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org