RabbitMQ .NET Client - Access to vhost refused for user

[Erik Mostert]

Hi guys

I stumbled into a weird situation and I hope someone can help.  

We have several virtual hosts configured on our server.  They are all configured in the same way and there is a single user who has access to all of them.  We ran some tests this morning and everything worked fine, but during one of the tests we suddenly started receiving the following exception:

The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=530, 

text="NOT_ALLOWED - access to vhost 'dyn_inbound_order' refused for user 'DynUser'", classId=10, methodId=40, cause=

I know this normally indicates that either the virtual host does not exist or that the user indeed does not have access, but this does not appear to be the case.  As shown below, the user in question is definitely configured to access the virtual host:

All of the other virtual hosts work fine, it is just the 'DYN_INBOUND_ORDER' one that causes a problem.  We have also tried to connect with another user which worked before, but this also failed. 

Could it be that the record for this vhost somehow corrupted in RabbitMQ's database?

Any help will be appreciated.

Regards
Erik Mostert

[Karl Nilsson]

Hi,

What version of RabbitMQ are you using? Is the problematic vhost listed in `rabbitmqctl list_vhosts`. Is there anything else in the server log of interest>

Cheers

Karl

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Karl Nilsson

Pivotal/RabbitMQ

[Erik Mostert]

Hi Karl

Thank you for your quick reply.

We are currently running 3.6.10.  

rabbitmqctl lists the problematic vhost, along with the rest.

As for the logs, I could not find anything of interest.  The only "funny" thing that we did was that we deleted the queues for all of the vhosts this morning prior to running our tests.

Please let me know whether you need any other information.

Regards

Erik Mostert

On Tuesday, 25 July 2017 11:51:10 UTC+2, Karl Nilsson wrote:

Hi,

What version of RabbitMQ are you using? Is the problematic vhost listed in `rabbitmqctl list_vhosts`. Is there anything else in the server log of interest>

Cheers

Karl

On 25 July 2017 at 10:07, 'Erik Mostert' via rabbitmq-users <rabbitm...@googlegroups.com> wrote:

Hi guys

I stumbled into a weird situation and I hope someone can help.  

We have several virtual hosts configured on our server.  They are all configured in the same way and there is a single user who has access to all of them.  We ran some tests this morning and everything worked fine, but during one of the tests we suddenly started receiving the following exception:

The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=530, 

text="NOT_ALLOWED - access to vhost 'dyn_inbound_order' refused for user 'DynUser'", classId=10, methodId=40, cause=

I know this normally indicates that either the virtual host does not exist or that the user indeed does not have access, but this does not appear to be the case.  As shown below, the user in question is definitely configured to access the virtual host:

All of the other virtual hosts work fine, it is just the 'DYN_INBOUND_ORDER' one that causes a problem.  We have also tried to connect with another user which worked before, but this also failed. 

Could it be that the record for this vhost somehow corrupted in RabbitMQ's database?

Any help will be appreciated.

Regards
Erik Mostert

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Karl Nilsson

Pivotal/RabbitMQ

[Michael Klishin]

Are you sure that the internal authn/authz backend used? If not, or it is only used for authn,

it does not matter what permissions you have configured via CLI tools or management UI.

http://www.rabbitmq.com/access-control.html

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Erik Mostert]

Hi Michael

When we configured the server, we performed a vanilla installation and added the virtual hosts and users via the management UI.  We did not add any other authentication mechanisms or plug-ins. 

I did notice something this afternoon.  We can use the any of the users who have access to the vhost and successfully log in via the management UI and manually add queues to the problematic host.  We only encounter the problem when we try to create a connection via the .NET client to the specific vhost.

Fortunately this is a new implementation for us and we are still in testing, so I think I will re-install the server tomorrow.  I will provide an update tomorrow morning after the re-install.

Regards

Erik Mostert

[Karl Nilsson]

Have you tried to remove and re-create the vhost? Or perhaps remove and re-apply the permissions.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Karl Nilsson

Pivotal/RabbitMQ

[Erik Mostert]

Yip.  We tried both, but no change.

I am busy writing a new test application to see whether I can replicate the problem.  If the new app succeeds, then I suspect the problem is in our code.

I will give an update a little bit later.

Regards

Erik Mostert

[Erik Mostert]

My test application succeeded in connecting to the vhost and managed to create a queue.

The funny thing is that I use the same method of connecting to the host as our existing code.  In any case, I will investigate our existing code and will provide an update in case we find something useful.

Thanks for your time.

Regards

Erik Mostert