Private version of public notebook

1

Is there a way to view the private version of a publicly published notebook?

I seem to recall that if I kept the URL for the private notebook, I could still access it in “private view” (which could access secrets) - but maybe I’m mistaken here. If it is so, how can I retrieve this URL?

My current solution involves making a private fork of my public notebook. But if I’m not mistaken, it means I have I have to refork the public notebook each time I make a change to it? That’s a bit bothersome.

Thanks in advance!

2

Hi @norswap,

Secrets (and DatabaseConnections) are not available in public notebooks — even in their private, unpublished versions. You’ll have to fork a new private notebook to add secrets to it.

If you don’t mind sharing, I’d love to hear you explain a little bit more about your use case. If you intend the notebook to be published, then why are you using secrets? Or is this a case of a frequently evolving notebook maintaining two copies — one without secrets, public, for documentation; and one with secrets, private, for actual internal use?

If the latter is the case, I’d recommend creating a private notebook and importing cells from your public, reference notebook, instead of forking it. That should allow you to continue to upgrade the public version, while the private one receives the benefits.

1 Like
3

Hey Jeremy,

Thanks for your answer!

I have this notebook (Fitbit / Nicolas Laurent | Observable) which is a simple app that can transfer some data from your Fitbit account to a Google Sheet spreadsheet.

The idea is simply to share it, and let users enter their own API keys as secrets.

Some more context on my blog (norswap · Wrangling Fitbit's and Google Sheets' API) but the part you might be interested in:

I found Observable to be particularly interesting. Of course I could have trivially built the same thing as a local webpage, but Observable makes it easier to share with people and easier to access from other devices (including phones). It’s also nice to be able to do good looking literate programming.

If public notebooks can’t use secrets, then I wonder - what’s the use case? Obviously, avoiding copy/pasting API keys everywhere, but I had thought it was about sharing notebooks where users could plug in their own data from their secrets.

If the latter is the case, I’d recommend creating a private notebook and importing cells from your public, reference notebook, instead of forking it. That should allow you to continue to upgrade the public version, while the private one receives the benefits.

I’m not sure this would work with this being an “app” — I want it ready to use, with the users needing only to input their API keys + some parameters (but at the same time I don’t want to use an input field for the keys, forcing users to input them on each use).

That being said, forking is fine. It’s just that if I make a change, I have to refork it, which is just a very minor annoyance, but I thought I would check to make sure.

I don’t expect this particular notebook will change a whole lot. But I can imagine cases where notebooks would be updated frequently, and it could be cool to let “users” (forkers) know that a newer version of the upstream notebook is available.

PS: I’m hijacking this thread to ask a small question I had — is there a better way to perform OAuth than a redirect to the notebook? I’m not an expert, but Fibit’s implem of Oauth redirects you to something like <page of your choice>?session_key=XXXX. Is there a way to do that somewhere out of the main window to avoid a reload? (And without hosting a server elsewhere with the sole purpose of reading the URL!) I tried with popups, only to be defeated by CORS protection when tried to pipe to the result back to the main page. I tried to use an iFrame, but I can’t put ObservableHQ pages in a frame (which I suppose there are many good reasons for).

4

Very cool!

Since the notebook is meant for individual use — transferring the data to a Google Sheet when you push the button — why not just use a regular text input for the API key?

That way, the key is not stored, the user doesn’t have to fork the notebook, and the user doesn’t even need to have an Observable account at all.

You can also have the notebook work with either a text input or a Secret, allowing people to try it out first, and then fork it and write in their Secret if they’d like to keep a more permanent copy.

I’m not 100% positive about what’s possible with OAuth and iframes, but I don’t believe there is. That said, having OAuth redirect back to the notebook page with the querystring params appended should work just fine. Notebooks are allowed to read the query parameters of their parent window:

5

Here’s an option:

It allows users to enter a custom value for the secret, which is persisted to local storage.

6

Since the notebook is meant for individual use — transferring the data to a Google Sheet when you push the button — why not just use a regular text input for the API key?

In the text you quote just below, there is:

but at the same time I don’t want to use an input field for the keys, forcing users to input them on each use

So basically, this is supposed to be used multiple times and copy/pasting three keys each time is a bit of a hassle.

I’m not 100% positive about what’s possible with OAuth and iframes, but I don’t believe there is. That said, having OAuth redirect back to the notebook page with the querystring params appended should work just fine. Notebooks are allowed to read the query parameters of their parent window

Yep, that’s how it works in the notebook currently.

@j-f1 Nifty! I’ll definitely use it if I make another app-style notebook that I have to update frequently.

I have no further questions or comments, thanks for the prompt answers!