No matter what html code I entered on the widget, there is no display.
Opened a support case three days ago but no word from Solarwinds yet.
Code:
<iframe width="450" height="260" style="border: 1px solid #cccccc;" src="">thingspeak.com/.../iframe>
Update for those of you tracking this issue yourself or have a case open that is referencing CORE-17163.
I confirmed with engineering that this was an intentional change introduced in the 2020.2.5 release to address a potential security vulnerability. Essentially, this is a simple matter of trust and how much you trust whomever is hosting the site you are embedding as an iFrame into your Orion dashboards. This is not a vulnerability specific to Orion, but really just iFrames in general.
Who is affected? Theoretically, anyone who already using a Custom WIdget containing an iFrame should be unaffected when they upgrade. Only when a new Custom HTML widget is added to a page should these new security restrictions take effect.
How do I restore the previous functionality in the Custom HTML resource that I was afforded prior to upgrading to 2020.2.5 or later?
Provided you assume, understand, and accept the risks associated with embedding iFrames into your Orion dashboards, restoring this functionality to its prior functional state is actually fairly simple. All you have to do is open Database Manager or SQL Studio and execute the following query. Note that you will need to replace 'DATABASENAME' with the name of your Orion database.
Update [DATABASENAME].[dbo].[WebSettings] SET [SettingValue] = 'False' Where [SettingName] = 'HTMLResourceSanitizationEnabled'
Once executed, the iFrames in your Custom HTML resources should begin working after refreshing the page. No need to reboot or restart services.
To re-enable the security protections again, simply run the following SQL query.
Update [DATABASENAME].[dbo].[WebSettings] SET [SettingValue] = 'True' Where [SettingName] = 'HTMLResourceSanitizationEnabled'
I have confirmed this is not working in my lab environment also. I've logged this as a bug internally and am tracking it under CORE-17163
Does it work on other pages? This looks like a summary page. I am using that widget, but with no iframe on node pages. It works (Orion version 2020.2.4)My code looks like
$(document).ready(function() {$("tr").filter(function(){return $("td:last",this).is(":empty");}).hide();});${Caption} in ServiceNow${ServiceNowID}${Caption} in ExtraHop${ExtraHopID}Manager: ${Support_Group_Manager}${Support_Group_Mgr_Email}Primary Analyst: ${Primary_Analyst}${Primary_Analyst_email}
I also tried it with: <iframe title="Wikipedia page for Avocados" src="">en.wikipedia.org/.../Avocado"></iframe>And that worked. it might just be the properties in the iframe?
I have added this HTML to my 2020.2.4 instance and it works correclly:
https://thingspeak.com/channels/1320249/widgets/279522
Not sure, but are you suggesting that even if you do a simple <H1>Hello World</H1> this fails to display in the widget? If this is the case, I would be inclined once reviewed the OrionWeb.Log file to rebuild the website.
Tried what you suggested and still not displaying, I'm on 2020.2.5.
Still no joy with 2020.2.5
Results in
Ahh, if you are experiencing this on 2020.2.5, @aLTeReGo is definitely the man for this, as if no HTML code is being processed, something is not working in this RC
I have a strange problem I have 2 custom html's that are housed in the same folder with different names. One of mine works and one doesn't. I'd love dearly for someone to explain how that happened.
If these are hosted by IIS, I would recommend verifying the NTFS file permissions are the same.
Any update from Solarwinds on this fix?
Thank you, this workaround worked.
Is there a "Secure" option to insert html resources?
Could the approved "Sanitized" setting be configured on the view/widget definition in the database? I would prefer to do the approval individually rather than enabling "Sanitizing" for all existing views that might have been created without my knowledge.
This change affects only Custom HTML widgets. The setting is binary. Either 'on' or 'off' for all Custom HTML resources.
Understood. Thanks for the quick response! However, should there be some field in the Views table or the Resources table that suggest "sanitization" has occurred? If setting to False, then refreshing a view allows for content to be displayed for new views, then setting back to True to block the Custom HTML widget for newly created views, it would make sense there would be extra fields or a security table to separate existing from new would exist somewhere.
The WebSettings table did not include the 'HTMLResourceSanitizationEnabled' record. When I added, set the value to false, then refreshed a view with custom HTML, the resource links still do not display (broken links). I copied the Custom HTML text from an existing View which displays properly, but it does not display in the new view.
What version of the Orion Platform are you currently running?
2020.2.6. I thought since the security implementations applied to 2020.2.5 and later, so I expected it to apply.
In the 2020.2.6 release this setting was moved to centralized settings.
https://www.solarwinds.com/documentation/en/flarehelp/npm/content/core-custom-html-resource.htm?cshid=OrionPHResourceCustomHTMLText
OK... finding out additional details as I explain the issue to other team members....
The broken links appear to be due to implied source locations (which previously worked) rather than using a full URL reference. For instance, previously I could use <img src="images/picture.jpg">. When this is copied to another Custom HTML widget for display, the broken link icon displays. However, when the image source is changed to a URL <img src="">orionserver.us/.../picture.jpg">.
I am still only able to get images to display with HtmlResourceSanitizationEnabled unchecked. Waiting about 5 minutes, then checking HtmlResourceSanitizationEnabled and refreshing the page will not display any image content. Text and other HTML formatting (including href) displays properly.
I also experimented with the EnableHtmlLinkSanitization setting. When unchecked and then rechecked, the first URL reference in the Custom HMTL widget appears to get "hashed" but still displays the image properly (with HtmlResourceSanitizationEnabled unchecked). All other URLs are unchanged and display as expected.
@aLTeReGo Could you confirm or refute the behavior described above as by design?
Why is it that you are disabling HtmlResourceSanitizationEnabled and then re-enabling it?