How can I access virtual host using rhea with TLS? #392
Comments
|
I suspect pika is using an older version of AMQP. AMQP 1.0 has no equivalent of the old 'virtual host'. According to the rabbit mq docs you should use a prefixed value for the hostname in connection open: https://github.com/rabbitmq/rabbitmq-server/tree/main/deps/rabbitmq_amqp1_0#virtual-hosts |
|
Thank you for your reply. It is as you aid Pika is using version 0.9. But I have another problem then. I am using rabbitmq and keycloak with rabbitmq Logs in rabbitmq now: It looks like user is known and authenticated and connection is open but when I call open_sender() method, second authentication is doing and its failed. I tried many different hostname in rhea and virtual hosts in rabbitmq. When i not provide |
|
I'm sorry, I think the rabbitmq team would probably be better placed to help you there. From the log, the virtual host is clearly being extracted correctly, i.e. you are passing it from the rhea client correctly. |
|
I've got a similar problem, don't know if it's related or not. const container = rhea.create_container();
container.on('message', function (context) {
console.log(context.message.body);
context.connection.close();
});
container.once('sendable', function (context) {
context.sender.send({body:'Hello World!'});
});
const keyFile = '< key file >';
const certFile = '< cert file >';
const caFile = '< ca file >';
const ca = fs.readFileSync(caFile);
const cert = fs.readFileSync(certFile);
const key = fs.readFileSync(keyFile);
const opts: rhea.ConnectionOptions = {
host: host,
port: port,
transport: 'tls',
key: key,
cert: cert,
ca: [ca],
hostname: `${host}`,
properties: {
target: target,
}
};
const connection = container.connect(opts);
connection.open_receiver(target);
connection.open_sender(target);
connection.send({ body: 'Hello world' });And I get the following error I've tried setting Looks to me like the user in my certificates are not valid, but... How and where do I set the VirtualHostNode? Should that not match the queue name? |
|
I believe the VirtualHostNode is specified by |
|
@grs Thank you for your prompt reply. The string I pass to open_receiver/open_sender, try to set in the connection object is definitely not 'default'. Where to set the target other than the places mentioned above? |
|
Is this also rabbitmq broker? I'd advise asking them on their list what the error means. I may be misunderstanding what they call VirtualHostNode is. |
|
I've asked the server people to clarify what they mean by their messages. They are generating AMQP endpoints to connect to by calling a REST API, that returns the following relevant information "host": "< AMQP host >", I assume that the 'target' is the queue name, which I've asked them to confirm. I assume that the target is the queue name, meaning I should put it as a parameter to I also see in the documentation, talk about In the meantime I also checked connection.js, lines 438 to 443 reads The open_sender call looks a tad strange to me, I tried modifying it to But the error is still the same with "default" what I think is what should be a queue name in the "VirtualHostNode" :| |
|
The send on Connection is deliberately not using a specified target. It is a so called 'anonymous' sender, in which each message sent would have a a 'to' property that would indicate where it should go. The normal use is to create a sender, specifying a specific target, and then to invoke send on that sender object. |
|
The term VirtualHostNode is not one that comes from AMQP. In AMQP a broker queue could certainly be referred to as a node. There is no field explicitly named virtual-host, though there is a What might hekp is to get a protocol trace from one side or the other, either through logging (e.g. DEBUG=rhea* for rhea) or with wireshark or similar. That way the actual interaction over the wire is clear. |
|
Thank you for clarifying The server is a Apache QPID, and they call I set DEBUG=rhea* in my .env file and don't get any logs. I try to do $export DEBUG=rhea* but to no avail. Any suggestions where to set this value if I'm working from a jest test? In any case, I managed to get a wireshark capture of traffic during a test run, please find the file attached. Just remove the png- extension on the file and open in wireshark 🙏 |
|
Sorry, because the traffic is encrypted using TLS, the wireshark trace isn't helpful. You will need logging. Exporting the env var in the terminal you are running a test from should work fine. If you are running it through some IDE, that may require alternative configuration. You can also set it in code, but you have to make sure you do so before loading the rhea module, e.g. |
|
Alright, thank you for looking into this. The debug trace is attached below. Something happens when the connection is opening up. Digging some more and seeing this #324 Made me set rhea:io [connection-1] connected 192.168.18.10:52963 -> 13.49.84.232:5671 +4s |
|
Hi @mattiaskjellsson, did you end up with solution? I'm facing the same problem and couldn't find anything but this thread |
Hi @natallia-ivanchuk yes, I found a solution. Not sure exactly what it was though, but the comment above mentions Something like this worked in the end. |
I am able to connect now but I am not able to send something to rabbitmq (client is only authenticated but access to virtual host is not granted). Rabbitmq log:
2023-01-12 14:17:13.577765+00:00 [info] <0.5611.0> accepting AMQP connection <0.5611.0> (172.18.0.1:46954 -> 172.18.0.3:5671) 2023-01-12 14:17:13.583163+00:00 [info] <0.5611.0> AMQP 1.0 connection <0.5611.0>: user '63ec2047-6689-45c0-981d-f9b127a6bb7f' authenticatedI am using the same server with python pika and it working correctly:
2023-01-12 14:18:29.938260+00:00 [info] <0.5640.0> accepting AMQP connection <0.5640.0> (172.18.0.1:54738 -> 172.18.0.3:5671) 2023-01-12 14:18:29.943712+00:00 [info] <0.5640.0> connection <0.5640.0> (172.18.0.1:54738 -> 172.18.0.3:5671): user '63ec2047-6689-45c0-981d-f9b127a6bb7f' authenticated and granted access to vhost '/'How can I manage? I can't see params to select virtual host in docs.
The text was updated successfully, but these errors were encountered: