On 04/08/2010 03:11 PM, Rajith Attapattu wrote:
Gordon, are you planning to make the change ?
If you are volunteering, that would be greatly appreciated! If not, yes,
I will make the change.
Regards,
Rajith
On Thu, Apr 8, 2010 at 8:54 AM, Gordon Sim<[email protected]> wrote:
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]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
