secret references not recognized inside of Jupyter notebook (.ipynb)

[rdhyee]

In my experience, 1Password secret references (https://developer.1password.com/docs/cli/secrets-reference-syntax/) are not being recognized in the context of Jupyter notebooks by the op-vscode -- even I see the secret reference being recognized in .py files for example. For example:

In contrast:

I'm tempted to run vscode under the 1Password cli (op) directly with op run code to work around this problem, but I understand that this might be the most secure thing to do. Is that true?

Are others having the problem of secret references not working inside of a .ipynb context?

[maxcohen55]

Same here 👍 Any updates on this?

[ApprenticeofEnder]

I have confirmation on this as well. I'll see if I can look into it!

[ApprenticeofEnder]

Not sure if this is a clue, but I took a look at the concatenated output of a Jupyter notebook. However, looking at the concatenated output of a Notebook file reveals this:

$ cat jupyter_test.ipynb 
{
<--SNIP-->
    "source": [
        "API_USERNAME = \"op://Work/TestCreds/username\""
    ]
<--SNIP-->

Interesting. I thought the escaped quotes were interfering, but no, the regex doesn't need the quotation marks. Still, maybe it was reading out the file as it was on disk?

I converted the .ipynb into a JSON file, since that's literally the format it was in:

cat jupyter_test.ipynb > json_test.json

And would you look at that. It recognizes the thing in JSON!

I have a feeling this is something to do with how Jupyter noteboks are rendered in VSCode. Would need some further digging.

[ApprenticeofEnder]

I've also discovered that VSCode supports formatting of notebooks. Wonder if we can hook into similar behaviour.

Formatter Action source code

[jodyheavener]

Hey all, thanks for raising this issue. We currently have parsers that work with JSON, YAML, and ENV syntax, and then a more general-purpose parser for other text-based formats. I am going to look further into this, but I believe the issue is that Jupyter format is not a regular text-based format and will require a special parser. Adding a feature request label to hopefully have this investigated further. Thank you!