feat: Support username/password for local broker authentication#3823
Conversation
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! 🚀 New features to boost your workflow:
|
| None => Err(CertificateError::IoError { | ||
| path: path.as_ref().to_owned(), | ||
| error: std::io::Error::other("File content is empty"), | ||
| }), |
There was a problem hiding this comment.
This error has to be removed as the MQTT specification states that you can send a username without password. However, both username and password are required for MqttOptions::set_credentials() in rumqttc, so I'm not sure how empty password is addressed in rumqttc.
There was a problem hiding this comment.
I checked how MqttOptions::set_cedentials() behaves in the packet level.
In the MQTT specs level, there are username flag and password flag. So, "empty password" and "password not set" are different. The former, the password flag is set but password is empty string. The latter, the password flag itself isn't set.
"Empty password" exmaple:
mosquitto_pub -h 127.0.0.1 -u testuser -P "" -t test -p 1883 -m message"Password not set" example:
mosquitto_pub -h 127.0.0.1 -u testuser -t test -p 1883 -m messageBack to rumqttc. Their API offers only set_credentials(username, password). I provided the empty string to the second argument as below.
mqttoptions.set_credentials("username", "");Then, I ran the rumqttc client and confirmed the password flag was not set in the CONNECT packet. This means, rumqttc treats "empty password" equals to "password not set".
crates/common/tedge_config/src/tedge_toml/tedge_config/mqtt_config.rs
Outdated
Show resolved
Hide resolved
4a67eee to
f3adf15
Compare
Robot Results
|
0f9b7df to
34b2eab
Compare
tests/RobotFramework/tests/mqtt/local_broker_authentication/local_broker_authentication.robot
Show resolved
Hide resolved
tests/RobotFramework/tests/mqtt/local_broker_authentication/local_broker_authentication.robot
Outdated
Show resolved
Hide resolved
tests/RobotFramework/tests/mqtt/local_broker_authentication/local_broker_authentication.robot
Outdated
Show resolved
Hide resolved
| if let Some(client_auth) = cmd.client_auth_config.as_ref() { | ||
| config.with_client_auth(&client_auth.cert_file, &client_auth.key_file)?; | ||
| } | ||
| config.with_client_auth(cmd.auth_config.clone().try_into()?)?; |
There was a problem hiding this comment.
This is a nice improvement.
3fa0c0d to
306da78
Compare
27d1ab5 to
cb4c337
Compare
Signed-off-by: Rina Fujino <rina.fujino.23@gmail.com>
Signed-off-by: Rina Fujino <rina.fujino.23@gmail.com>
Signed-off-by: Rina Fujino <rina.fujino.23@gmail.com>
cb4c337 to
eb289af
Compare
Since thin-edge#3823, an inappropriate warning is printed when a non-TLS connection is established to the local broker: $ tedge mqtt sub te/# 2025-11-18T14:47:04.179834205Z WARN MQTT: Connecting on port 1883 for insecure MQTT using a TLS connection This warning is inappropriate because the connection is *not* established over TLS: neither a client certificate nor root certificates have been configured. Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
Proposed changes
Support username/password authentication to the MQTT local broker.
Prepare a
/etc/tedge/.passwordfile. The first line is read as the password.Then, configure these parameters.
If encrypted connection is activated in the broker, configure any secure port (e.g. 8883) and give the CA certificate file or the directory (below is example)
Todo:
tedge mqtt pub/subworkstedge-agent&tedge-mapper-c8ywork with mosquitto bridgetedge-agent&tedge-mapper-c8yworks with build-in bridgeTypes of changes
Paste Link to the issue
#3807
Checklist
just prepare-devonce)just formatas mentioned in CODING_GUIDELINESjust checkas mentioned in CODING_GUIDELINESFurther comments