Dashboard configuration edit/save: Is there a limit for (mqtt) password length

General
#1

  1. My goal is:
    use the dashboard to change device configurations - in cases where the configured MQTT password is long.

  2. My actions are:
    making dashboard configuration changes to a device that is working when a configuration is flashed with mos

  3. The result I see is: I have a project that uses very long MQTT password (currently 162 characters). The password is working fine when setting it in mos.,yml, building and updating the whole firmware.
    With this long password the content of the password configuration gets garbled. After updating the configuration through the dashboard the MQTT from the mongoose-os device stops working as it cannot log in.

When making changes to the configuration with the Dashboard tools everything is fine if the passwords have normal length.

  1. My expectation & question is:
    Is there a limit for the length of the password in the dashboard configuration window / save?

Could be something else. But limited size for the password handling in the dashboard save seemed like a reasonable suspect…

Pertti

#2

It looks like a bug.
Does it manifest only for the long password?
Saving other options is fine?
Could you start developer tools in a browser and catch the Config.Set REST request & reply please?

#3

Hi, sorry for the slow reply. Did not notice any notification.
The UI has changed since but still getting the same error.

The Config.Set from browser console (no console errors):

The request content:
{“config”:{“mqtt”:{“pass”:“SharedAccessSignature sr=SlowManagerIoTHub-test.azure-devices.net/devices/FE5742039118&sig=1234/XRrvVf3Rrc0vi3QJ1MgT2wN/FdT%2BwW2hnG4mMM%3D&se=1560779232&skn=device”}}}
and the response:
{
“saved”: true
}

Then Config.Save
{“reboot”:true,“try_once”:true}
->
{
“saved”: true
}

And then the subsequent Config.Get partial response, the line with error:
“mqtt”: {
“pass”: “”,

For a few first experiments with a long password, I got about the right password, just <10 of the first characters were garbled. Then it was truncated to empty string. Updating with a short password fixes this.

Passwords up to about 80 characters seemed to work, and around 90 character long passwords start getting garbled. Sometimes truncated for empty string, sometimes the first characters replaced like this:
“”,5�?edAccessSignature…"

Pertti

#4

SharedAccessSignature ? I smell Microsoft…

Maybe the problem is with incorrect escaping?

Try to set the password using mos config-set mqtt.pass=.... and see if that works well.

#5

There is no Windows involved when this error happens. The target for MQTT is an Azure server. But the configuration&dashboard is used from a Mac. The error happens both with Crome and Safari.

mos config-set to my understanding works only on locally connected devices? We would need to update remote devices.

What kind of escaping is needed for the mqtt.pass - or is it just a string? We can check that.

After several experiments, it seems that it is the &-characters that cause the trouble. If I remove the three occurrences of & in the password line, dashboard works ok.

Can I somehow escape the characters in the dashboard in such a way that it would be stored as a & in the MongooseOS device?

Pertti

#6

Ok so that’s it.

The configuration is JSON. And thus, the JSON strings that are used in the configuration, should be properly escaped. You can use some free online JSON escape/unescape tools to escape your password, and test.

w.r.t. Microsoft - I was under impression that Azure is Microsoft’s product.

#7

The password we use is valid JSON. There is no problem having a &-character in JSON, it does not need to be escaped: https://www.json.org/
The same string works when set in mos.yml

Nevertheless, tried to replace & with \&. mdash gives an error “SyntaxError: Unexpected token & in JSON at position 1541”

Could it be that the &-escaping is needed in the HTML/form/web part? That is hard to tell without looking how the dashboard is implemented…

(Azure is Microsoft, but no Microsoft product is yet involved when this problem arises. Once the password setting is correct, then it will connect to a Microsoft server…)

#8

Some trial-end-error experiments

\\& fails
&amp; fails

#9

I’ve mos config-set debug.level=3 followed by mos console, and in the mDash UI, set the mqtt1.pass to 1&2. I can see that the UI sends the data as expected:

47
Screenshot 2019-05-20 at 16.19.47.png1388Ă—518 89.9 KB

However, in the device console logs, I see this:

[May 20 16:16:46.917] mg_rpc.c:482            0x3fff0ff4 GOT FRAME (96): {"id":4,"method":"Config.Set","params":{"config":{"mqtt1":{"pass":"1\u00262"}}},"src":"$sys/d7"}

Notice the "params":{"config":{"mqtt1":{"pass":"1\u00262"}}}, . The ampersand was marshalled by mDash into \u0026, and that is the reason why the parser on the device side gets confused. The parser is https://github.com/cesanta/frozen, which croaks on the \u… escapes:

Thus, the solution is either to make frozen recognise at least simple one-byte unicode escapes, or to make the mDash not escaping ASCII range.

Let me follow up further on that.

For now, you can use the mos command line tool to set the field value:

mos --port wss://YOUR_API_KEY@mdash.net/api/v2/devices/YOUR_DEVICE_ID/rpc config-set mqtt.pass=...
#10

The JSON parser fix is pushed.

It’ll take some time to propagate. Use the mos tool for now.

#11

Thanks for figuring out where the problem was and for the frozen fix!

I did not manage to update the confs remotely from my Mac as I get these errors from mos
WebSocket connection failed: Invalid HTTP response code returned. Missing rpc-ws library?: bad status.
I get this after both “mos update latest” and “mos update latest”. Tried some “go get …” libs but did not figure it out.

Let’s see if the mdash.net could be used with “mos --port mqtt://mdash.net:1883…” way

At least this will be fixed once the changes propagate so not that big issue to us any more.

1 Like