You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## What?
If the new config setting `authorization_failure_disclosure`
is set to `true`, (`false` by default), then some RabbitMQ authorization
backends (internal, HTTP, OAuth 2.0) will return the reason why access
was denied to the client. (In future, additional backends can be modified
to return a reason.)
## Why?
This helps debugging and troubleshooting directly in the client.
Some clients might not have access to the RabbitMQ logs, for other
clients it's cumbersome to correlate authz denial in the client with
logs on the broker.
For example, in dev environments, it may be useful for clients to learn
why vhost/resource/topic access was denied for a given OAuth 2.0 token.
Another example is that some customers would like to pass the reason why
authorization was denied from their custom HTTP auth backend via
RabbitMQ back to the client.
## How?
Authz backends can now return `{false, Reason}` as an alternative to
just `false` if access is denied.
For security reasons, the additional denial reason by the authz backend
will be returned to the client only if the operator opted in by setting
`authorization_failure_disclosure` to `true`.
Note that `authorization_failure_disclosure` applies only to
already authenticated clients when they try to access resources (e.g. vhosts,
exchanges, queues, topics). For security reasons, no detailed denial reason is
returned to the client if **authentication** fails.
0 commit comments