Send HTTP POST body or URL changing &LT to a less-than when the field name in the form starts with LT

🛎️ Get Help
1

Working with an advanced tweaking a WLED device's settings, trying to make an HTTP POST to the endpoint that configures the "Time and Macros" page - two fields in the form have a name that starts with LT so they get translated to < any HTML encoding should not be taking place without the semi-colon after ( <   > etc ), but for sure HTML encoding should not be processed in a POST body/URL.

example form data from sniffing my PC browser calls to the WLED device:
NT=on&NS=0.wled.pool.ntp.org&CF=on&TZ=4&UO=0&LTR=N&LT=10.00&LNR=W&LN=-10.00&O1=0&O2=29&OM=0&CY=23&CI=12&CD=25&CH=0&CM=0&CS=0&A0=0&A1=0&MC=0&MN=0&MP0=21&ML0=0&MD0=0&MP1=0&ML1=0&MD1=0&MP2=0&ML2=0&MD2=0&MP3=0&ML3=0&MD3=0&W0=255&H0=0&N0=0&T0=0&M0=1&D0=1&P0=12&E0=31&W1=255&..... etc - you get the idea

the problem fields are near the beginning: &LTR=N&LT=10.00 (in case this gets HTML mangled, ampersand L T R equals N ampersand L T equals 10.00)

I tried putting it directly in the URL and in a form body but they both get HTML-mangled immediately when leaving the body field, or immediately in the URL. I tried content type Text as well but it does the same thing in the body field.

I also tried pre-HTML-mangling the ampersand to & and it looks like that fixed the issue but after a save and go back in its back to the converted-to-less-than symbol status ( i.e. &amp ;LTR= )

2

just tried setting a local variable as string and the same thing happens to the form field names

3

This is incorrect behavior for a URL. URL encoding is different from HTML Entity encoding. And from your comments you seem to know this.

So my question is: what exactly is doing this? It needs to be fixed.

4

That's my question... something in the Hubitat UI must be doing the conversion thinking it is HTML when I just want it to be taken as plain text. Shall I dig into the javascript of the UI to find out what event is triggering it?

Looks possibly related to Characters are removed in body for POST - #9 by ChrisP but I'm not putting in HTML - the hub is converting it TO HTML.

5

As a workaround, try using % encoding to trick it into not seeing the LT. In place of the L, put %4C. It's the same thing to a URL, but maybe it won't trigger the HTML encoder.

6

Thanks for the suggestion! I was pondering doing the URL encoding but hadn't decided which characters I should do... This seems to have done the trick.

7

In general, &lt; should get converted, while &lt should not. Whatever's making the change is squarely wrong.

1 Like
8

I am wondering if this is more to do with restrictions HE applies in certain parts of the UI around text that can be entered. My memory of this being applied was more to do with device preferences, but would make sense if it was broader than just that page

@bravenel will hopefully be able to at least confirm if I am on the right track.

9

Any update on this by any chance? I have come up with another work-around for now outside of Hubitat but it would be nice to get it to work here as well.

11

Sorry, had this mixed up with something else.... You would need to direct your question to HE developers I expect

12

I believe the issue is with how things get displayed in the logs vs. actual values getting mangled.
I've whitelisted org.apache.commons.lang3.StringEscapeUtils for the next release, and

httpPost([ uri: "http://localhost:9090/", body: "NT=on&LT=test1&NS=test2&NR=off", textParser: true ]) { resp ->
    log.debug org.apache.commons.lang3.StringEscapeUtils.escapeHtml4(resp.data.text)
}

shows expected values while

httpPost([ uri: "http://localhost:9090/", body: "NT=on&LT=test1&NS=test2&NR=off", textParser: true ]) { resp ->
    log.debug resp.data.text
}

indeed displays a mangled string as samples show.
In this example, http://localhost:9090/ is a simple HTTP echo service I use locally.

2 Likes
13

The WLED device got all mangled in the original post with those 2 fields being screwed up the rest of the form was also screwed up and I had to go in and manually fix the settings - so it isn't just the log in my case.