Allow embedding/opening from within JupyterLab?

JupyterLab introduced a help menu entry pointing to discourse but it does not open currently, see: Jupyter Forum (discourse) does not open correctly in 3.1.0.a12 · Issue #10398 · jupyterlab/jupyterlab · GitHub

Do you think it is possible to configure it in a way that supports iframe embedding in JupyterLab UI?

Who is the right person to make the configuration change?

CC @jasongrout, @choldgraf

Does the change need to be in discourse or jupyterlab?

It looks like the Discourse HTTP headers prohibit embedding of the site, e.g.:

content-security-policy: upgrade-insecure-requests; base-uri 'none'; object-src 'none'; script-src https://discourse.jupyter.org/logs/ https://discourse.jupyter.org/sidekiq/ https://discourse.jupyter.org/mini-profiler-resources/ https://aws1.discourse-cdn.com/standard11/assets/ https://aws1.discourse-cdn.com/standard11/brotli_asset/ https://discourse.jupyter.org/extra-locales/ https://sjc4.discourse-cdn.com/standard11/highlight-js/ https://sjc4.discourse-cdn.com/standard11/javascripts/ https://sjc4.discourse-cdn.com/standard11/plugins/ https://sjc4.discourse-cdn.com/standard11/theme-javascripts/ https://sjc4.discourse-cdn.com/standard11/svg-sprite/; worker-src 'self' https://aws1.discourse-cdn.com/standard11/assets/ https://aws1.discourse-cdn.com/standard11/brotli_asset/ https://sjc4.discourse-cdn.com/standard11/javascripts/ https://sjc4.discourse-cdn.com/standard11/plugins/; manifest-src 'self'
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-xss-protection; 1; mode=block

Exactly.

  1. Is this possible to relax this policy (i.e. is discourse self-hosted, or is it somewhat out of our control)?
  2. Is this a good idea to relax this policy?

Alternatively, JupyterLab could open the discourse in a new window instead of in main area tab (which has both advantages and disadvantages, so I have no strong preference, but all other documentation/help links already open in main area widgets so that would be a bit inconsistent).

It seems it is not exactly/easily possible for discourse-hosted instances: Support embedding Discourse in an iframe - feature - Discourse Meta (apparently JuliaLang had similar issue some time ago), but a potential existence of such option was mentioned in that thread (and of course with self-hosted instance everything is possible).

As for whether this is a good idea: it would be ok-ish if we had a list of sites that we can allow-list (presumably mybinder.org, localhost (? - this might be problematic, but is how most users access JupyterLab!), etc.), but we won’t be able to enlist sites for custom deployments. Maybe it would be safer to just change it in JupyterLab.

Please let me know what you think.

Personally I’m against putting external sites in iframes. I find that the smaller size of an iframe makes it harder to view and navigate many websites, and the styling and navigation of the embedded website almost never matches that of the parent site. Throw in conflicting keyboard shortcuts for added fun. This is very much my personal opinion though so feel free to ignore it :smile:

Looking at your linked PR/issue there’s no discussion about the pros/cons of embedding Discourse vs open it in a new tab, so it might be useful to know the background before making a decision?

1 Like