A github discussion (as opposed to a SIP) may be sufficient here, but open to either. Clearly there's lots to talk about around the topic of supporting html. I did some work around bringing in more support and consistent support across the board in the past, mostly for links (`<a />`) in various table views (table viz, results, samples) and cringe when I see places where it's not supported properly like I don't think it's supported in dashboard-level filters at the moment, unclear about explore filters (?)
Now https://github.com/apache/superset/issues/23047 bring an interesting point where sometimes you DONT want the link to render as a link, so there needs to be a way to tell the UI to NOT render the html Now for backwards compatibility, it'd be a breaking change to NOT render where it's rendered currently, so maybe <no-render>{stuff}</no-render> is no as elegant but better in terms of backwards compatilibty (?) I think it's fair to say that in most cases you'd want to render (I'd say 80%+ but maybe that's just me...) and we want for this to be the default so it can be discovered easily. On Fri, 8 Mar 2024 at 10:52, Evan Rusackas <e...@rusackas.com> wrote: > On a related note, I just came across this old issue requesting such a > feature. I’m going to move it to a Discussion since it’s not a bug, and we > can close it out if/when this feature expands beyond SQL Lab. Feel free to > add comments if you feel it’s warranted: > https://github.com/apache/superset/issues/23047 > > Evan Rusackas > On Mar 8, 2024 at 9:47 AM -0700, Michael S. Molina < > michael.s.mol...@gmail.com>, wrote: > > It looks like I misunderstood the proposal. I was with the impression > that we wanted to render the Google page inside SQL Lab but the proposal is > just to switch the rendering of the result as HTML or plain text. If I > understood correctly this time, then I have no objections. > > > > Best regards, > > Michael S. Molina > > > > > On 8 Mar 2024, at 13:28, Beto Dealmeida <robe...@dealmeida.net.invalid> > wrote: > > > > > > Right, I'm not worried about security issues, since we already do this > by default and the current behavior can cause problems like stripping XML > tags from a string response! > > > > > > (To see what I mean, just run > > > > > > ``` > > > SELECT '<xml>hello</xml>' AS xml; > > > ``` > > > > > > in SQL Lab.) > > > > > > I was just wondering if people had different ideas on this. Eg, I > always thought we could/should implement per-column — we could have extra > metadata in the column indicating it should be rendered as HTML, or we > could use the Jinja macro that I suggested. > > > > > > But I'm OK with moving this forward based on lazy consensus without a > SIP, and maybe later we could start a discussion on rich rendering of data, > that's something that would be cool. Rendering images inline, exploding > nested data (structs and arrays) into multiple table cells, that kind of > thing. > > > > > > --Beto > > > > > > > > > > On 3/8/24 11:14 AM, Evan Rusackas wrote: > > > > It may also be worth noting that the current HTML rendering in SQL > Lab (which can’t be disabled by the user) respects Talisman configs, so it > can strip out the usual XSS concerns. > > > > > > > > Evan Rusackas > > > > > On Mar 8, 2024 at 9:09 AM -0700, Evan Rusackas <e...@rusackas.com>, > wrote: > > > > > Hi all, > > > > > > > > > > I’d spoken to Yanisa about this previously. This change was on > their list, and I had advised them that this change might be fine with lazy > consensus, but if there’s controversy, they could elevate it to a SIP. > > > > > > > > > > > > > > > My impression was that it’s not a big significant architectural > change or security risk since SQL Lab and other tables in Superset already > render HTML by default, so this doesn’t expose any new security risk. This > simply gives the user added control over this for certain use cases where > you’d want to disable the rendering. > > > > > > > > > > It might warrant some design discussion around the placement of > the switch, or where else we might be able to provide similar controls in > the future, but I don’t see anything controversial or architecturally > dangerous here that would’ve required a SIP. Let me know if I’m missing > something, as I may well be :) > > > > > > > > > > Thanks, > > > > > > > > > > Evan Rusackas > > > > > On Mar 8, 2024 at 7:28 AM -0700, Michael S. Molina < > michael.s.mol...@gmail.com>, wrote: > > > > > > Hi Yanisa, > > > > > > > > > > > > Thank you for the proposal. As Beto mentioned, the best way to > introduce new features to Superset is through the SIP process where we can > collectively collaborate on the proposal. I bet that during the SIP review > we’ll have many questions about the security implications of the proposed > feature and how it interacts with our current HTML rendering restrictions. > > > > > > > > > > > > To learn about SIPs, just check the link Beto provided. > > > > > > > > > > > > Best regards, > > > > > > Michael S. Molina > > > > > > > > > > > > > On 8 Mar 2024, at 10:44, Beto Dealmeida > <robe...@dealmeida.net.invalid> wrote: > > > > > > > > > > > > > > Do we have a SIP written for this? (see > https://github.com/apache/superset/issues/5602 for context) > > > > > > > > > > > > > > Also, did you consider having some kind of macro that would > indicate to the frontend that the result should be rendered as HTML? For > example, this: > > > > > > > > > > > > > > ``` > > > > > > > SELECT product, {{ render_html('product_url') }}, price > > > > > > > FROM some_table > > > > > > > ``` > > > > > > > > > > > > > > Could generate SQL like this: > > > > > > > > > > > > > > ``` > > > > > > > SELECT product, '<RENDER>' || product_url || '</RENDER>', price > > > > > > > FROM some_table > > > > > > > ``` > > > > > > > > > > > > > > Which would then be detected by the frontend and we'd render > `product_url` as HTML. > > > > > > > > > > > > > > Then this could be defined at the column level, and people > would be able to create derived columns in datasets that are automatically > rendered as HTML. > > > > > > > > > > > > > > --Beto > > > > > > > > > > > > > > > On 3/7/24 10:56 PM, Treesak, Yanisa (Agoda) wrote: > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > I hope this email finds you well. I wanted to reach out to > propose an idea for enhancing Superset SQLLab's functionality. > > > > > > > > > > > > > > > > Currently, the platform renders any HTML command in the > result table, which can sometimes obscure the full HTML in the request > body. To address this, I suggest implementing an option button that enables > users to control the rendering of HTML in the result table. > > > > > > > > > > > > > > > > > > > > > > > > This feature would provide users with more flexibility and > clarity when viewing HTML content within SQLLab. I believe it could greatly > improve the user experience and streamline workflows. > > > > > > > > > > > > > > > > I would appreciate your consideration of this proposal and > would be happy to discuss it further at your convenience. > > > > > > > > > > > > > > > > Thank you for your time and attention. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > *Yanisa Treesak* > > > > > > > > > > > > > > > > Data Engineer > > > > > > > > > > > > > > > > Agoda Services Co., Ltd. > > > > > > > > > > > > > > > > a *Booking Holdings* company > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > This message is confidential and is for the sole use of the > > > > > > > > intended recipient(s). It may also be privileged or > > > > > > > > otherwise protected by copyright or other legal rules. If > > > > > > > > you have received it by mistake please let us know by reply > > > > > > > > email and delete it from your system. It is prohibited to > > > > > > > > copy this message or disclose its content to anyone. Any > > > > > > > > confidentiality or privilege is not waived or lost by any > > > > > > > > mistaken delivery or unauthorized disclosure of the message. > > > > > > > > All messages sent to and from Agoda may be monitored to > > > > > > > > ensure compliance with company policies, to protect the > > > > > > > > company's interests and to remove potential malware. > > > > > > > > Electronic messages may be intercepted, amended, lost or > > > > > > > > deleted, or contain viruses. > > > > > > > > > > > >
