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.
