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-originfromst.html(which means your Disqus workaround will no longer work
) - 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-originsandbox flag for any iframe content that is being served by the Streamlit webserver. - Currently, all
st.htmlandst.declare_componentiframes are served by Streamlit webserver, which means they cannot use theallow-same-originflag. - 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-origincomponents 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-originsolutions 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
(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