Allow embedding/opening from within JupyterLab?

Site Feedback
1

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?

2

Who is the right person to make the configuration change?

CC @jasongrout, @choldgraf

3

Does the change need to be in discourse or jupyterlab?

4

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://global.discourse-cdn.com/standard11/assets/ https://global.discourse-cdn.com/standard11/brotli_asset/ https://discourse.jupyter.org/extra-locales/ https://sjc6.discourse-cdn.com/standard11/highlight-js/ https://sjc6.discourse-cdn.com/standard11/javascripts/ https://sjc6.discourse-cdn.com/standard11/plugins/ https://sjc6.discourse-cdn.com/standard11/theme-javascripts/ https://sjc6.discourse-cdn.com/standard11/svg-sprite/; worker-src 'self' https://global.discourse-cdn.com/standard11/assets/ https://global.discourse-cdn.com/standard11/brotli_asset/ https://sjc6.discourse-cdn.com/standard11/javascripts/ https://sjc6.discourse-cdn.com/standard11/plugins/; manifest-src 'self'
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-xss-protection; 1; mode=block
5

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).

6

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.

7

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
8

Two quick thoughts

  • Agreed that it’d be useful to think through the pros and cons of embedding vs just linking out to discourse. I think there’s need to be a clear argument that it is worth the extra complexity (or, show that the complexity is very minimal)
  • just a reminder that our discourse has approximately zero dedicated resources, so unless we get a clear commitment of maintenance time from others I think that we should rule out anything that requires extra work other than tweaking an option or two one time
9

Just a quick update: currently JupyterLab just uses a link as implemented in https://github.com/jupyterlab/jupyterlab/pull/10574. While I don’t see it to be a priority to make it work in the embedded mode, the cost/benefit ratio may change once someone commits to maintaining a standalone JupyterLab App in which case opening the browser should be avoided.