On Wed, Sep 25, 2019 at 9:17 PM Justin Bertram <[email protected]> wrote:
> I only have a passing familiarity with the MQTT protocol and the Paho MQTT So do I, it is still less than few hours :) > in general clients will > often "fire and forget" messages based on their quality-of-service > configuration. I used QOS = 2, which is called "at most once", which means client should wait for response. I used 2 in both cases. > For example, many JMS client implementations will fire and > forget non-persistent messages. [...] > Perhaps your client is doing this. No, you can see in logs that message sequence from mosquitto_pub contains PUBREC, PUBREL and PUBCOMP. According to http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html (and I believe nothing changed in later versions) these are respectively: Publish received - meaning that AMQ received the message. Publish release - meaning that message can be released by the client (if I understand it correctly) Publish completed - meaning that message publishing ended successfully. In fact now that I look at it there is no message that would indicate that client is not allowed to publish. > Perhaps you need to implement some kind of listener to get notified of an > exception when sending a message. I've been thinking about it, but if client isn't subscribed to any topics (and in my case it might be not subscribed to anything) there is no way to send any info back, except maybe forcibly closing the connection. And now, after reading some more on aforementioned site I found the following: If a Server implementation does not authorize a PUBLISH to be performed by a Client; it has no way of informing that Client. It MUST either make a positive acknowledgement, according to the normal QoS rules, or close the Network Connection [MQTT-3.3.5-2]. Well duh. Since AMQ chooses to make a positive acknowledgement instead of closing connection, I'll try to close it myself and see what happens. Thank you for your answer. JD > Justin > > On Wed, Sep 25, 2019 at 6:54 AM Jędrzej Dudkiewicz < > [email protected]> wrote: > > > I wrote simple authenticating/authorizing plugin that reads CN field > > in certificate passed by the client and decides which topic/queue can > > be created/written to/read from by that client. It works but I have > > two issues, one described here and the other one being this: > > > > http://activemq.2283324.n4.nabble.com/Authorization-plugin-don-t-know-what-to-do-with-client-attempting-to-write-to-weird-advisory-topic-tp4752509.html > > (maybe I should somehow migrate it here?). > > > > I wrote my plugin using > > org.apache.activemq.security.AuthorizationBroker as a reference. I > > extend BrokerFilter class and override i.a. "send()" method. If access > > check fails (so client can't send messages to this destination), I > > throw SecurityException, just like AuthorizationBroker. This works > > flawlessly If I use OpenWire client (written in Java in 50 lines or > > so). Sending message to the destination that I have no access to > > results in client error and even exception detailing what went wrong > > contains message from exception thrown by my plugin. > > > > My problem is that similar client that uses paho.mqtt.cpp library > > (built upon paho.mqtt.c library) reports that everything went well. I > > also tried using mosquitto_pub to the same effect. Output of > > mosquitto_pub execution is below: > > > > jd@gojira:~/queues/client/testclient$ cat MOSPUB.sh > > mosquitto_pub --key cli01.key \ > > --cert cli01.pem --cafile test-root-ca.crt \ > > -h localhost -p 1883 -t hello -m napis -d -q 2 > > jd@gojira:~/queues/client/testclient$ bash MOSPUB.sh > > Enter PEM pass phrase: > > Client mosqpub/14778-gojira sending CONNECT > > Client mosqpub/14778-gojira received CONNACK > > Client mosqpub/14778-gojira sending PUBLISH (d0, q2, r0, m1, 'hello', > > ... (5 bytes)) > > Client mosqpub/14778-gojira received PUBREC (Mid: 1) > > Client mosqpub/14778-gojira sending PUBREL (Mid: 1) > > Client mosqpub/14778-gojira received PUBCOMP (Mid: 1) > > Client mosqpub/14778-gojira sending DISCONNECT > > > > Logs from ActiveMQ look like this (most of INFO log entries are > > produced by my plugin): > > > > TRACE | TCP consumer thread for ssl:///0:0:0:0:0:0:0:1:52520 starting > > DEBUG | MQTT Client mosqpub/14788-gojira requests heart beat of 60000 ms > > DEBUG | MQTT Client mosqpub/14788-gojira established heart beat of > > 60000 ms (60000 ms + 30000 ms grace period) > > INFO | add conn: class org.apache.activemq.broker.ConnectionContext null > > INFO | add destination: > > org.apache.activemq.broker.ConnectionContext@5b0c4682 > > destinationtopic://ActiveMQ.Advisory.Connection tempfalse > > DEBUG | MQTT Using subscription strategy: mqtt-default-subscriptions > > DEBUG | MQTT Client mosqpub/14788-gojira connected. (version: 3) > > TRACE | MQTT Rcv PUBLISH message:1 client:mosqpub/14788-gojira > > connection:ID:gojira-33277-1569362891935-3:5 > > TRACE | MQTT-->ActiveMQ: MQTT_MSGID:1 client:mosqpub/14788-gojira > > connection:ID:gojira-33277-1569362891935-3:5 > > ActiveMQ_MSGID:ID:gojira-33277-1569362891935-3:5:-1:1:1 > > INFO | **************************** SEND > > INFO | SENDING TO: hello topic://hello > > INFO | CASC: CAN WRITE: zs.leaf.P-00666 hello > > INFO | CASC: CAN'T WRITE AND NOT SERVICE. ACCESS DENIED. > > WARN | Security Error occurred on connection to: > > tcp://0:0:0:0:0:0:0:1:52520, User zs.leaf.P-00666 can't write to > > topic://hello > > WARN | Failed to send MQTT Publish: > > TRACE | Error trace: {} > > java.lang.SecurityException: User zs.leaf.P-00666 can't write to > > topic://hello > > at > > zs.comm.amq.auth.CertAuthPlugin.send(CertAuthPlugin.java:124)[auth-0.0.1-SNAPSHOT.jar:] > > at > > org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:578)[activemq-broker-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:768)[activemq-client-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:336)[activemq-broker-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:200)[activemq-broker-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:45)[activemq-client-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.mqtt.MQTTInactivityMonitor.onCommand(MQTTInactivityMonitor.java:162)[activemq-mqtt-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.mqtt.MQTTTransportFilter.sendToActiveMQ(MQTTTransportFilter.java:106)[activemq-mqtt-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.mqtt.MQTTProtocolConverter.sendToActiveMQ(MQTTProtocolConverter.java:181)[activemq-mqtt-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTPublish(MQTTProtocolConverter.java:494)[activemq-mqtt-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.mqtt.MQTTProtocolConverter.onMQTTCommand(MQTTProtocolConverter.java:219)[activemq-mqtt-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.mqtt.MQTTTransportFilter.onCommand(MQTTTransportFilter.java:94)[activemq-mqtt-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.tcp.SslTransport.doConsume(SslTransport.java:171)[activemq-client-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)[activemq-client-5.15.10.jar:5.15.10] > > at > > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.15.10.jar:5.15.10] > > at java.lang.Thread.run(Thread.java:748)[:1.8.0_222] > > TRACE | MQTT Snd PUBREC message:1 client:mosqpub/14788-gojira > > connection:ID:gojira-33277-1569362891935-3:5 > > DEBUG | MQTT Client mosqpub/14788-gojira disconnecting > > INFO | REMOVING CONNECTION: > > org.apache.activemq.broker.ConnectionContext@5b0c4682 > > ConnectionInfo {commandId = 0, responseRequired = true, > > connectionId = ID:gojira-33277-1569362891935-3:5, clientId = > > mosqpub/14788-gojira, clientIp = tcp://0:0:0:0:0:0:0:1:52520, userName > > = null, password = *****, brokerPath = null, brokerMasterConnector = > > false, manageable = false, clientMaster = true, faultTolerant = false, > > failoverReconnect = false} > > null > > INFO | add destination: > > org.apache.activemq.broker.ConnectionContext@5b0c4682 > > destinationtopic://ActiveMQ.Advisory.Connection tempfalse > > DEBUG | Stopping transport ssl:///0:0:0:0:0:0:0:1:52520 > > TRACE | Closing socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: > > Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]] > > DEBUG | Closed socket 22fd81fb[TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: > > Socket[addr=/0:0:0:0:0:0:0:1,port=52520,localport=1883]] > > > > > > And of course message is not sent to the "hello" topic. My client > > behaves exactly the same, minus debug information on client side. > > > > My question is: is this an inherent problem of MQTT protocol or rather > > error in AMQ's implementation? > > > > This isn't really a big problem as well-behaving clients "have nothing > > to fear" during normal operation, but I can imagine that it will be a > > nightmare to debug in the field. > > > > Thanks in advance, > > -- > > Jędrzej Dudkiewicz > > > > I really hate this damn machine, I wish that they would sell it. > > It never does just what I want, but only what I tell it. > > -- Jędrzej Dudkiewicz I really hate this damn machine, I wish that they would sell it. It never does just what I want, but only what I tell it.
