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. > > > > > > > > >
