OAuth 2: Variable expansion not working for write permissions

[inseroaj]

Describe the bug

While #13894 seem to be resolved in version 4.1.1, it doesn't work for write permissions.

Reproduction steps

Consider a user test with the scopes rabbitmq.read:*/q-{name} rabbitmq.write:*/q-{name} where the name-claim contains the username.
Using the management UI, trying to retrieve messages from queue q-test works as expected, while trying to publish messages to that queue results in an Access Denied error.

Expected behavior

With the same resource permissions set for read and write, publishing a message should not fail when read doesn't.

Additional context

No response

[michaelklishin]

@inseroaj we do not guess in this community. It's on you to collect relevant logs and provide a set of steps to reproduce, not on us. All refused permissions will be logged, and at debug level, you will get a lot authN/autZ-related messages on top.

There is no such thing as "publishing to a queue" in AMQP 0-9-1. Unlike consuming from a queue, publishing requires exchange permissions, and the default exchange that the HTTP API publishing uses is no exception.

By the way, publishing over the HTTP API is a highly discouraged practice.

[inseroaj]

Just realized what you meant by there being no such thing as "publishing to a queue", and deleted my previous comment.
Obviously you were not talking about the management UI, but the fact that in the end, you always publish to an exchange.

Using the management UI's Publish message will attempt to publish a message to the amq.default exchange, and fail, since it doesn't match the write permission resource pattern */q-{name}.
Creating an exchange named q-test, and binding the similarly named queue to that exchange makes it work.

Sorry for the confusion, and thanks for your time.

[michaelklishin]

Correct, all publishing goes via an exchange, whether the default one, another pre-declared exchange (e.g. amq.topic) or an application0defined one.