Indeed, I understand that the proposal is to render HTML by default (as it is today) and optionally disable it. This would mean it’s non-breaking, and adds functionality rather than removing it.
Evan Rusackas On Mar 14, 2024 at 2:28 AM -0600, Carlos Alonso Vega <los...@unavarra.es>, wrote: > Hi all, > > Hope it is not late to add an opinion. In our case HTML rendering is > mandatory in charts and dashboards. Maybe in SQLab could be optional or > disabled (it could make sense to see actual data for debuging queries, and > rendered result could not be so necessary at that level.) > > We show rendered HTML data on dashboards and charts, specially links to > external parts of our ERPs, web pages and so. Without html rendering, in our > case, the funtionality of dashboards would be reduced drastically. > > So, for us default HTML rendering should be the way, but if it can be > disabled, it could be an interesting optional feature (if it not breaks > backward compatibility) > > Carlos > > > El 14/03/2024 a las 6:11, Evan Rusackas escribió: > > Hi all, > > > > I think we’re all caught up and on the same page here now. In short: > > • HTML would be rendered by default > > • This switch would effectively disable the rendering > > > > If that’s all it does,, it sounds like there are no objections. Maybe it > > was just a matter of wording, where it would be “Add option to DISABLE > > rendering of HTML on SQL Lab’s results table” In any case, I’m not sure if > > we’re now on track for lazy consensus, or if it needs to be re-proposed > > > > I’m +1 on this feature, and expect that it’ll spread to other tables (e.g. > > the Table viz) in the future. > > > > -e- > > > > Evan Rusackas > > On Mar 8, 2024 at 4:08 PM -0700, Maxime Beauchemin > > <maximebeauche...@gmail.com>, wrote: > > > 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 <a > > > href="https://urldefense.com/v3/__https://github.com/apache/superset/issues/23047__;!!D9dNQwwGXtA!Vy9ubuPwxELax75q1T8ZVzR1L9TPSA8ZjjyZY6_Ry4_dQlGkcS0FjFetXN9xnDATLQ9YtPAM3QqCOg$";>https://github.com/apache/superset/issues/23047</a> > > > 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: > > > > <a > > > > href="https://urldefense.com/v3/__https://github.com/apache/superset/issues/23047__;!!D9dNQwwGXtA!Vy9ubuPwxELax75q1T8ZVzR1L9TPSA8ZjjyZY6_Ry4_dQlGkcS0FjFetXN9xnDATLQ9YtPAM3QqCOg$";>https://github.com/apache/superset/issues/23047</a> > > > > > > > > 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 > > > > <a > > > > href="https://urldefense.com/v3/__https://github.com/apache/superset/issues/5602__;!!D9dNQwwGXtA!Vy9ubuPwxELax75q1T8ZVzR1L9TPSA8ZjjyZY6_Ry4_dQlGkcS0FjFetXN9xnDATLQ9YtPDitwGh9g$";>https://github.com/apache/superset/issues/5602</a> > > > > 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. > > > > > > > > > > > > > -- > <uLAzCV43449DSfau.png> > Carlos Alonso Vega > Jefe de la Sección Servicios Campus > Servicio Informático - Informatika Zerbitzua > Universidad Pública de Navarra - Nafarroako Unibertsitate Publikoa > +34 948 169652 > carlos.alo...@unavarra.es
