rabbitmq_auth_backend_http not sending vhost nor client_id anymore with v3.12.10

[headyj]

Describe the bug

We are using vhost field for our authentication process, but this field is missing after the update from rabbitmq v3.11.18 to v3.12.10

Reproduction steps

1. Install Rabbitmq v3.11.18
2. Configure rabbitmq_auth_backend_http
3. log the payload of rabbitmq_auth_backend_http somewhere, it will looks like this:

{"password":"****","vhost":"my-vhost","username":"my-username","client_id":"mqttjs_c5a43723"}

4. do the same using v3.12.10, payload is missing both vhost and client_id fields

Expected behavior

payload should be the same between both versions

Additional context

Rabbitmq installed on Kubernetes v1.27 using the Operator

Configuration

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbitmq
  namespace: rabbitmq
  annotations:
    prometheus.io/probe: "false"
    prometheus.io/scheme: "https"
    rabbitmq.com/operator-connection-uri: https://rabbitmq.my-domain.io
spec:
  image: rabbitmq:3.11.18-management
  persistence:
    storage: 10Gi
    storageClassName: ebs-storage-class
  rabbitmq:
    additionalPlugins:
      - rabbitmq_web_mqtt
      - rabbitmq_auth_mechanism_ssl
      - rabbitmq_auth_backend_http
    additionalConfig: |
      vm_memory_high_watermark.relative = 0.7
      auth_backends.1           = internal
      auth_backends.2           = http
      auth_http.http_method     = post
      auth_http.user_path       = http://rabbitmq-auth-proxy-server.rabbitmq-auth-server.svc.cluster.local/auth/user
      auth_http.vhost_path      = http://rabbitmq-auth-proxy-server.rabbitmq-auth-server.svc.cluster.local/auth/vhost
      auth_http.resource_path   = http://rabbitmq-auth-proxy-server.rabbitmq-auth-server.svc.cluster.local/auth/resource
      auth_http.topic_path      = http://rabbitmq-auth-proxy-server.rabbitmq-auth-server.svc.cluster.local/auth/topic
      raft.wal_max_size_bytes   = 64000000
  replicas: 3

[michaelklishin]

This is missing one crucially important step: the plugin does or does not do that in response to what client operations?

client_id, for example, won't be present for non-MQTT clients. In some contexts we do not yet have a virtual host to include, too. Authentication and virtual host selection in some protocols are two separate steps.

[headyj]

What I can say is that both our rabbitmq clusters share exactly the same configuration (except the version). So something should have change between both versions. I checked the documentation but could find any breaking change at least

[michaelklishin]

You are not providing a crucial piece of information, so we can only guess what has changed. And we do not guess in this community.

[michaelklishin]

It can be that your apps deployed to the 3.12.10 cluster are different from those in the 3.11 cluster. That will make a difference, regardless of the configuration.

[headyj]

That's the same application on which I'm switching the application configuration. That's why I thought that it was not so important to detail what it was doing, but I'll let one member of our team to explain what it does in detail.

[ansd]

FWIW 3.12.10 MQTT plugin does pass vhost and client_id to auth backends:

rabbitmq-server/deps/rabbitmq_mqtt/src/rabbit_mqtt_processor.erl

Lines 699 to 700 in 1f61ca8

	{vhost, VHost},
	{client_id, ClientId}]

[headyj]

I tested using openresty with a simple lua script which is the same on both clusters. v3.11.18 is logging both vhost an client_id, the other doesn't:

2023/12/20 14:52:08 [info] 1#1: *532 [lua] access_by_lua(proxy.conf:31):6: {"client_id":"mqttjs_858b280f","username":"my-username","vhost":"my-vhost","password":"******"}, client: 172.20.33.179, server: rabbitmq-auth-proxy-server, request: "POST /auth/user HTTP/1.1", host: "rabbitmq-auth-proxy-server.rabbitmq-auth-server.svc.cluster.local:80"

 2023/12/20 14:53:41 [info] 1#1: *1609 [lua] access_by_lua(proxy.conf:31):6: {"password":"*****","username":"my-username"}, client: 172.20.13.48, server: rabbitmq-auth-proxy-server, request: "POST /auth/user HTTP/1.1", host: "rabbitmq-auth-proxy-server-test.rabbitmq-auth-server.svc.cluster.local:80"

[michaelklishin]

Please put together an executable way to reproduce and publish it to GitHub.

If it uses Lua, that's fine, as long as we understand what to install (including Lua dependency management).

[headyj]

Then using the rabbitmq configuration from the initial ticket should be enough, then logging using openresty and the following configuration:

server {
      listen       80;
      server_name  rabbitmq-auth-proxy-server;     
      resolver kube-dns.kube-system.svc.cluster.local valid=5s;

      location /auth/user {
        add_header Custom-Header-1 $request_method;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Url-Scheme $scheme;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_method POST;
        proxy_http_version 1.1;
        set $namespace '';

        access_by_lua_block {
          ngx.req.read_body()
          local cjson = require "cjson"
          ngx.log(ngx.INFO, cjson.encode(ngx.req.get_post_args()))
        }
      }

      location /auth/vhost {
        return 200 'allow';                            
      }

      location /auth/resource {
        return 200 'allow';                      
      }

      location /auth/topic {
        return 200 'allow';              
      }
    }

[michaelklishin]

I'm afraid OpenResty is more than I can handle but we will try to reproduce using AMQP 0-9-1, MQTT and AMQP 1.0 clients

[horak90]

Hello, to add more information, we are using nodejs mqtt client in version 4.2.8 which is using the following connection options: { 'username': vhost:username, 'password': password }

[ansd]

@MarcialRosales dbffccb looks suspicious (part of #9052)

[michaelklishin]

According to @ansd, #9052 introduced this regression.

[michaelklishin]

#10200

[michaelklishin]

Now #10200 has been merged and backported, its v3.12.x, its backport can be tested using the following OCI image tag:

docker pull pivotalrabbitmq/rabbitmq:v3.12.x-otp-max-bazel

@headyj @horak90

[michaelklishin]

Or its 3.13 preview version:

docker pull pivotalrabbitmq/rabbitmq:36c6b547ee229b07067929d04e30841a974f632d-otp-max-bazel

in case the above tag does not yet include the backport.

[headyj]

Thanks a lot @michaelklishin, I will test it and let you know

[headyj]

@michaelklishin I can confirm that pivotalrabbitmq/rabbitmq:v3.12.x-otp-max-bazel is exposing again the vhost and client_id