Disqus integration

Custom Components
12

Hey @okld -

I have a bit of annoying Components API news that affects your Disqus component:

  • For the upcoming components open beta launch, we’re going to remove allow-same-origin from st.html (which means your Disqus workaround will no longer work :frowning:)
  • We’re not currently implementing a “allow users to opt in to unsafe components” workaround

There are several competing goals that led to this decision:

  • First, we want to make sure that Streamlit’s iframes are properly sandboxed. This means that we can’t use the allow-same-origin sandbox flag for any iframe content that is being served by the Streamlit webserver.
  • Currently, all st.html and st.declare_component iframes are served by Streamlit webserver, which means they cannot use the allow-same-origin flag.
  • There are a number of potential solutions to this issue (an “unsafe” flag, like you suggested; running a 2nd components-only webserver from within the Streamlit process; requiring that allow-same-origin components be served from a CDN or some other server; etc). We haven’t decided which of these - if any - we like.
  • We want to release the open beta soon - probably too soon to really evaluate all the allow-same-origin solutions and think about their impacts on the rest of Streamlit - and we don’t want to half-ass a solution that we later regret.

So, I have egg on my face for speaking too soon when I said “we’re going to come up with a solution to this before launch”! Apologies for that :frowning:

(And for anyone else reading this thread but not sure what it’s all about, the MDN iframe reference page has a decent explanation of the folly of the allow-same-origin + allow-scripts iframe sandbox tokens for iframe content that’s served from the same origin as its host page.)

Tim

2 Likes