Gordon, are you planning to 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] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
