Feature: Add support for AMQP 0.9.1 "update-secret"

[mortdiggiddy]

Feature: Add support for AMQP 0.9.1 "update-secret"

[cressie176]

Hi @mortdiggiddy,

I'm not getting much time to work on amqplib features at the moment, but if you or anyone else wanted to give it a go, the best starting place would be to familiarise yourself with how amqplib generates the RabbitMQ operation definitions.

There's a script called generate-defs which is called from the makefile. This downloads an old version of the RabbitMQ code generation spec from before update-secret was added.

You could try updating the makefile to download the latest spec is here and see if the tests still pass, then work out how to add the updateSecret method to the callback model and channel model. The RabbitMQ spec says update-secret returns a confirmation, so it should expect a reply.

[cressie176]

Hi @mortdiggiddy,

I've added an updateSecret method to both the callback and promise apis on this branch. Are you able to checkout the brandh and confirm everything works as you expect please?

await connection.updateSecret(Buffer.from('new secret'), 'some reason');

Because update-secret is a RabbitMQ extension you don't WireShark decodes both the operation and reply as Connection.Unknown

[mortdiggiddy]

I will be testing locally here in the next few days. Just adding this comment here for traceability.

The test will involve periodic OAUTH OpenID Connect token fetch from an IAM server, which dumps it into a running Rabbit MQ 3.12 Docker container instance equipped with the rabbitmq_auth_backend_oauth2 plugin.

Under normal conditions when this plugin is enabled and an RPC publish, send_to_queue, etc is invoked on AmqpConnectionManager from amqp-connection-manager (which delegates to amqplib) a 403 ACCESS_REFUSED error is thrown. This is one of the critical errors, which requires a closure of the client and all channels attached to it. A new client and channel must be created.

If this update is working, we can update the access token before expiration, and all is well.

It will be up to developers to integrate some type of automatic refresh mechanism that periodically checks for tokens approaching expiration, so that the update-secret method can be invoked before it expires with a new token. If operating entirely on the backend, this can be handled by REDIS using keyspace notifications, and using a SETEX to automatically expire a token when it reaches about 80% of its TTL (safety factor). Once the token is gone from REDIS, a notification can be sent to trigger the refresh.

[cressie176]

Any luck with the testing @mortdiggiddy?

[mortdiggiddy]

So far so good, a few more test and I will update this.