LOGIN  |  REGISTER
Smart Living Made Brilliant!
CASTLEOS FORUM

HomeBug Reports

A forum topic for reporting bugs and other issues with CastleOS

Virtual devices stopped working Messages in this topic - RSS

Scott Goffman
Scott Goffman
Posts: 111


9/15/2016
Scott Goffman
Scott Goffman
Posts: 111
When virtual devices were first added to CastleOS I set up a couple of them and they worked great. But in the last couple of beta builds, they've stopped working.

I noticed that in configuration.xml, ampersands in the commands were being URLencoded to "&"; is it possible that string is being used directly without being URLdecoded?

e.g. onCommand="http://192.168.1.91:8082/ajax_sendevent.lhtml?event=OpenTheaterDrapes&device=18" no longer works. (While entering the URL "http://192.168.1.91:8082/ajax_sendevent.lhtml?event=OpenTheaterDrapes&device=18" directly in a browser does still work.)

Oh, and I'm currently on 1.3.3031 (2.0 Beta).
Thanks,

-Scott
edited by sgoffman on 9/15/2016
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/15/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
Hmm, nothing changed in the betas related to this. What happens if you edit the device? Does it show as encoded still?
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/15/2016
Scott Goffman
Scott Goffman
Posts: 111
Yeah, if I edit out the encoding in the xml directly, CastleOS adds it back in within a few seconds. The URL displayed in the "Edit Device" UI is decoded.
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/15/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
To manually edit the XML you need to stop the service, otherwise edits will be overwritten every 5 seconds.
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/15/2016
Scott Goffman
Scott Goffman
Posts: 111
I did try that, but the strings get re-encoded after the service starts up again (or after I try using the device links, not sure which).
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/15/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
I just checked the code...there's no url encode or decode on the the virtual device links. CastleOS treats it as straight strings. What browser is this happening in? Can you send me the config file so I can see it?
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/16/2016
Scott Goffman
Scott Goffman
Posts: 111
Okay, that's odd. I'll try some other browsers.


Attachments:
Configuration[1].xml
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/16/2016
Scott Goffman
Scott Goffman
Posts: 111
I've tried creating a virtual device under Chrome, IE, and Safari, and in each case any ampersand in the on/off URL would be stored in the config file as "&". Do you not see the same that behavior on your end?

It's also possible that this is a red herring, and has nothing to do with why the virtual devices stopped working. They broke when I edited them to change what group(s) they were in; I was assuming that the stored URL was modified at that point, but I don't have a config backup from before that change to compare against.
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/16/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
This used to save correctly before the betas, correct? I can't find what would've changed with relation to this...
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/16/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
I can confirm the issue has been replicated though, working on it...
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/16/2016
Scott Goffman
Scott Goffman
Posts: 111
Correct, it was only after saved the devices in the Beta that they stopped working.
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/16/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
It looks like the & character is being encoded to prevent a XSS attack by default by .NET. I'll have to override that behavior...
edited by ccicchitelli on 9/16/2016
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/16/2016
Scott Goffman
Scott Goffman
Posts: 111
Or keep the security and add a WebUtility.HtmlDecode() on reading the URL back from the config...
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/16/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
I just posted an update with a potential fix for this. It will still show as encoded in the XML, but in the GUI and in the backend, it will be decoded. The encoding issue is also what broke the URL from being called, so it should be a two for one fix. Thanks!
0 link
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390


9/16/2016
Chris Cicchitelli
Chris Cicchitelli
Administrator
Posts: 3390
Scott Goffman wrote:
Or keep the security and add a WebUtility.HtmlDecode() on reading the URL back from the config...



Yup, that's exactly what I did. I didn't realize .NET XML processor encoded by default, and we never tested it with unsafe text. I think you're the first!
0 link
Scott Goffman
Scott Goffman
Posts: 111


9/16/2016
Scott Goffman
Scott Goffman
Posts: 111
Thanks Chris, that fixed it! And I would not have expected that behavior as default from the XML processor either...

-Scott
0 link