Explain the data flow for Jupyter notebook files hosted on a private URL

[Noah Reddell]

If we want to embed a Jupyter notebook from a private URL like a private GitHub, where is that data in the file exposed/processed/rendered?

In the local web browser only?   In Atlassian Cloud servers only?  In Mibex Software servers?

Dropbox is listed as supported.  What permissions are needed on the dropbox link?  Can these be private/restricted links -- i.e. not public?

My company uses Box instead of Dropbox.  We use the Box plugin for Confluence and this works nicely to embed attachments otherwise private. Our best workflow would probably be to embed Jupyter notebooks stored on Box too.

[Roman Stoffel · Accepted solution]

Hello

I'm a Developer at Mibex, so here's the answers:

> Where is that data in the file exposed/processed/rendered?

The data is rendered in the browser itself, not on the server.

The data passes through does pass through a Mibex server: The server does not store or process it. It only relays the data back to the Browser, where it is rendered.

> My company uses Box instead of Dropbox.

We only support public documents, reachable by plain link for Dropbox. And we have some URL recognition (Copy & Paste) for Drop box.
So, for Box: If you can get a raw URL to the document, you should be able to set it as URL.
However, that URL needs to be without authentication. Maybe Box supports something like a 'anyone with this URL can access the document'. Then you can try that URL.

Roman Stoffel

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

I'm not sure this is really a question for Atlassian.  The only bit that really relates to Atlassian is that Confluence can host files as "attachments".

So yes, you could attach your files to pages, they will be stored on Atlassian's Cloud storage, and you get to them via the page they are attached to.  The Box app can move that storage to Box services, and the access to them would then be controlled by Box.  Similarly with Dropbox or any other storage services.

But that has nothing to do with the data flow or usage of the notebooks. 

If you're going to be actively working with them, I wouldn't recommend plain attachments - they are not exposed as files you can directly edit, on a file storage system, you'll need to be downloading them, making edits and then manually re-uploading them as a new version.

[Noah Reddell]

Thanks I think my question would be better addressed by Mibex since I'm specifically interested in their options to *not* attach the files as Confluence page attachments.  (doesn't work well with our imagined workflow)

[Nic Brough -Adaptavist-]

Yep, internal Confluence attachments aren't a good place for storage, they're only really useful for being supporting content on pages.