I am having trouble with the HTML formatting in a driver attribute being stripped out when "Save Preferences" is done. In my case, <p> and <br> tags are being removed. From testing this is done during initialize in the driver, as by the time the code to plug the data into the HTML is executed, the HTML is already stripped. Don't know if this is browser related (tried in Edge, Brave and Chrome) or if Hubitat is doing it. I haven't been able to figure out how to work around it, as if I substitute > and < then that just gets directly displayed in the output as < and > . The HTML attribute is being used to format the data display in a dashboard tile, and it was working a few months ago.
1 Like
Believe I read that there is an additional check now for input fields (preferences, dashboard variables, etc.) that strips out tags to prevent HTML injection.
1 Like
I've heard something similar. Couldn't see anything in the 2.2.8 notes though.... Or too much written about it elsewhere...
1 Like
I also raised a bug on this. It is more than just html tags getting stripped. It is anything between < and > even if they are not html commands.
1 Like
So is there a good workaround? My weather dashboard is a real mess now! 
What I am trying to do is display the temperature in large text and then the Feels like and Dew point in smaller text, and I have no idea how to do that without the html tags.
1 Like
I've often wondered whether we could store html tiles as static html files that are overwritten instead of an attribute. Not sure if it is a viable option or not...
As far as I can tell, you can still use HTML tags in attributes set from within a driver.
So I think the right answer is to make the preference input format be something other than the raw HTML (like an enum of formatting combinations or something) and then translate that internally in the driver to the correct HTML. Having a user input raw HTML that you render directly is a pretty big potential vulnerability.
Note that what I suggested for deliberate HTML preferences input does not address what @snell mentioned where otherwise valid inputs are being treated like they're HTML. That seems like a bug that Hubitat should fix.
2 Likes
It is a risky method, true. But making users figure out some special formatting that will then be translated would be pretty unlikely to work well.
I can confirm you can still use HTML you generate. One if my drivers creates a list of all of the matching attribute from each child. For example, if you want to know all the temperatures across multiple children, it will put each one with a
in between so each one is on a separate line. That still works just fine.
Thanks for all the inputs, definitely helps to get other points of view. For now I'm just leaving off some inputs so I can at least get the temp and humidity. Then I can think about how to modify the driver to put in the tags that I want. It's ugly but I think it will work, this is just for me so I don't have to worry about users 
.
I agree that it seems like there aren't any limits on attributes. My driver that publishes jpeg images through a data URL still works correctly, so I'd guess that there is no filtering at all on outputs.
I disagree that it is not possible to make a usable preference that will work with this new filtering on preferences inputs. For example, an enum that says ["bold", "bold w/ italics", "italics"] for style or ["red", "green", "orange"] for color is:
- More straightforward to use than telling every user to brush up on their HTML
- Easy to code to in the driver; and
- Won't have HTML filtered based on this new restriction.
It might be a little more limiting because it would only support that specific functionality, but how much extra HTML formatting is it really necessary to support, anyway? 
Could do a simulated bbcode, i.e. use [ ] instead of < >ā¦
My MQTT Text driver has a setText() command and also allows you to set a prefix and suffix that is added to the text. All allow you to include html tags ā¦. Suffix is particularly useful for appending units of measurement to a displayed value, prefix for setting font/colour and you can create multi line tiles.
Ignore the MQTT naming , I just created it to display random payloads from there. It doesnāt need MQTT at all
https://raw.githubusercontent.com/xAPPO/MQTT/beta3/MQTT%20Text%20beta%203e%20(test)
What I was referring to was a straight replacement for how users were using the html with my drivers (based on @mircolino's original HTML Template). Most were using it to add font style/color/size, and paragraph or break points.
So I would need to come up with my own formatting and then search and replace (in addition to the attribute search and replace).
So what was (for example):
<font size=2 color="#00AA00">Temperature=${ temperature }</font></br><font size=2 color="#AA0000">Humidity=${ humidity }</font>Just replacing the symbols would be far easier... But it would not remove the risk of html injection.
2 Likes
I could probably throw together a BBcode type routine that you could use as a method (maybe using the library functionality that we now have), i.e.
String bbToHtml( String bbInput) {
ā¦
return htmlStr
}
The āprotectionā being that if it wasnāt a recognized code it wouldnāt get parsed into HTML.
Thinking codes for bold, italic, underline, color, size and newline to startā¦
2 Likes
I like the idea of using [] instead of <> and then substituting in the driver. For my purpose, I only need paragraph and break but for other people something more generic would be better. I wish I better understood why Hubitat is worried about HTML injection.
This seems to be working:
https://raw.githubusercontent.com/thebearmay/hubitat/main/libraries/bb2Html.groovy
Codes supported:
underline: [u]some Text[/u]
italics: [i]some Text[/i]
bold: [b]some text[/b]
newline: some Text[br]next line of text
color: [color=xxxxxx]some Text[/color] (where xxxxxx is the RGB hex code)
font size: [size=9999]some Text[/size]
You can have multiples embedded as long as your end tags are aligned correctly.
2 Likes
