Page History

...

Here the 'client' users is only give rights to PUBLISH messages using the key 'example.RequestQueue'.
The 'server' user is allowed to publish to 'tmp_*' and 'TempQueue*' keys. The reason there are two values here is due to changes in the naming of temporary queues during the example's development. However, what occurs here is that the 'server' is granted permission to publish messages to any routing key that begins with 'tmp_' or 'TempQueue', the '*' matching is only completed at the end of the key so entries such as 'Special*Key' are not allowed.

...

This section allows the granting of permissions to Consumers. There are two formats the <queue> entry can take:
*Users can be granted permission to a named queue by the use of the <name> field.
*Users can be granted permission to ALL temporary queues with the addition of the <temporary/> key.

These two formats can be combined to allow the consumption from a named queue and temporary queues. However, care must be taken if using multiple <queue> entries as access to temporary queues will be defined by the last <queue> definition. This is a known issue.

<!-- This section grants users the ability to consume from the broker -->
<consume>
    <queues>

        <!-- Allow the clients to consume from their temporary queues-->
        <queue>
            <temporary/>
            <users>
                <user>client</user>
            </users>
        </queue>


        <!-- Only allow the server to consume from the Request Queue-->
        <queue>
            <name>example.RequestQueue</name>
            <users>
                <user>server</user>
            </users>
        </queue>

    </queues>
</consume>

CREATE Section

This section allows the granting of permissions to create new queues as used by Consumers.

<!-- This section grants clients the ability to create queues and exchanges -->
<create>
    <queues>
        <!-- Allow clients to create temporary queues-->
        <queue>
            <temporary/>
            <exchanges>
                <exchange>
                    <name>amq.direct</name>
                    <users>
                        <user>client</user>
                    </users>
                </exchange>
            </exchanges>
        </queue>
        <!-- Allow the server to create the Request Queue-->
        <queue>
            <name>example.RequestQueue</name>
            <users>
                <user>server</user>
            </users>
        </queue>

    </queues>
</create>

Known Issues

{anchor:issue-temporary

Granting temporary queue and named queue consume rights

When defining a <queue> entry the existence of the <temporary/> key grants access to temporary queues. However, the lack of the key denies access to temporary queues. As a result if there are multiple <queue> entries the last entry will specify the value for access to temporary queues. i.e. In this example it is expected that 'client' can consume from temporary queues and named queue 'exampleQueue2'. Infact what will happen is that the user will only have access to 'exampleQueue2'.

        <queue>
            <temporary/>
            <users>
                <user>client</user>
            </users>
        </queue>
        <queue>
            <name>exampleQueue2</name>
            <users>
                <user>client</user>
            </users>
        </queue>

To work around this issue the correct definition would be:

...

        <queue>
            <name>exampleQueue2</name>
            <users>
                <user>client</user>
            </users>
        </queue>

        <queue>
            <temporary/>
            <users>
                <user>client</user>
            </users>
        </queue>

The last <queue> entry sets access to the temporary queues. In this simple example where there is only a single named queue it would of course be correct to combine the definitions as follows:

            
        <queue>
            <temporary/>
            <name>exampleQueue2</name>
            <users>
                <user>client</user>
            </users>
        </queue>