The broker appears to use NotAllowedException[1] in most places when
authorisation fails. This seems wrong to me as NotAllowedException is
used for specific types of invalid command requests (e.g. declaring an
existing exchange with a different type, or trying to create exchanges
with prohibited prefixes). As it stands it is not possible to realibly
distinguish between these two very different situations in code.
A more appropriate exception for authorisation failures would seem to be
UnauthorisedAccessException[2] which is only used in one place (when a
message is sent with a userid that differs from the authenticated id).
I propose that we fix this. Obviously this breaks backwards
compatibility to a degree, but I think in this case it is justified. At
worst it would require applications to reconsider catching
UnauthorizedAccessException wherever they are currently explicitly
catching NotAllowedException.
--Gordon
[1] Described in specification as indicating: "The peer tried to use a
command a manner that is inconsistent with the rules described in the
specification."
[2] Described in specification as indicating: "The client attempted to
work with a server entity to which it has no access due to security
settings."
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
