Skip to content

add frontend panel and add docker instructions #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

Jas0nch
Copy link

@Jas0nch Jas0nch commented Mar 30, 2025

This Pull Request contains the following changes:

  • gitignore change to exclude junit.xml file created by jlpm test
  • README improvement to add develop instructions using docker
  • in-memory/localStorage connector fixes of list function to return all secrets if query parameter is absent
  • Add a side panel show secrets filtered by namespace.

There're also a lot of Todos/Improvements by introducing this Pull Request:

  • better UI/UX design
  • should we expose the secrets value?
jupyter-secrets-manager-side-panel.mov

Copy link
Collaborator

@brichet brichet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Jas0nch for working on this.

I left some comments below.

.gitignore Outdated
@@ -123,3 +123,6 @@ dmypy.json

# Yarn cache
.yarn/

# Test results
junit.xml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
junit.xml
junit.xml

style/base.css Outdated

.jp-SecretsPanel-add-form-buttons button {
flex: 1;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
}
}

@@ -34,7 +43,16 @@ const manager: JupyterFrontEndPlugin<ISecretsManager> = {
connector: ISecretsConnector
): ISecretsManager => {
console.log('JupyterLab extension jupyter-secrets-manager is activated!');
return new SecretsManager({ connector });
const secretsManager = new SecretsManager({ connector });
const panel = new Panel();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably build the side panel in another plugin, to be able to disable it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it too much to have the UI in another plugin? Do you have a use case in mind where we want to enable the secrets manage functionality but disable the UI?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It already works to automatically populate inputs without UI, see #8 (comment).

src/index.ts Outdated
const secretsManager = new SecretsManager({ connector });
const panel = new Panel();
panel.id = 'jupyter-secrets-manager:panel';
panel.title.icon = logoIcon;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is already a lock icon in Jupyterlab, we should reuse it.

import { lockIcon } from '@jupyterlab/ui-components';

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, I'll change to reuse that.

@brichet
Copy link
Collaborator

brichet commented Mar 31, 2025

I wonder how we could handle namespaces in the panel.
The idea of the namespace is that each extension provides its own namespace.
In the long run, it would be really nice to isolate the the namespaced secrets from other extensions, to avoid malicious usage.

Maybe for a first implementation, the secrets manager could provide a list of existing namespaces, which would populate a drop down in the widget.

@Jas0nch
Copy link
Author

Jas0nch commented Mar 31, 2025

Maybe for a first implementation, the secrets manager could provide a list of existing namespaces, which would populate a drop down in the widget.

Thanks @brichet to review my PR. I agree with you on this. Actually I'm thinking should we make it further to notebook level? It would be great to have the capability to grant/revoke a secrets to a notebook to get more fine-grained access control. But namespace level can be the first implementation.

I'm also very curious on the vision of this plugin, in the long run, how would it work? It will populate the secrets to kernel, right? It will also accept other plugin's code to add secrets, right? Anything else? Is there a documentation?

I was reading jupyterlab/jupyter-ai#1237 and found that there's already something developing. So I'm thinking if we should gather some input from jupyter-ai team to see how the secrets manager could be evolved.

@jtpio jtpio added the enhancement New feature or request label Mar 31, 2025
@brichet
Copy link
Collaborator

brichet commented Mar 31, 2025

I was reading jupyterlab/jupyter-ai#1237 and found that there's already something developing. So I'm thinking if we should gather some input from jupyter-ai team to see how the secrets manager could be evolved.

Indeed, we mentioned it quickly during a jupyter-ai meeting but did not mention it in the jupyter-ai issue. This is really at early stage currently.

It will populate the secrets to kernel, right?

Currently it works in the frontend only, but we should indeed think of a way to send the secrets to the kernel.

It will also accept other plugin's code to add secrets, right?

The way it works currently (frontend only):

  • a plugin 'attach' an input element to the secretsManager, associated to a namespace and an input ID (here).
  • the secretsManager queries the secretsConnector to look for a secret with the namespace/ID provided. If there is one, the input is populated with the secret value.
  • if the user update the secret, the value is updated using the secretsConnector.

For example, this is used in jupyterlite-ai, from this PR.

Plugins should probably not add secrets, but rather allow associating a namespace/ID to a secret by the user.

@Jas0nch
Copy link
Author

Jas0nch commented Apr 1, 2025

Let me check the usage and think about how can I improve this PR

manager: ISecretsManager;
}

const EyeIcon = () => (
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't find a good import for these eye icons, please let me know if any better eye icons

@Jas0nch
Copy link
Author

Jas0nch commented Apr 2, 2025

Hi @brichet , I read the jupyterlite-ai usage of the secrets manager and now I understand how it works. I have update a new version of the PR along with the description and demo, please take a look when you have time.

I still have some questions and want to discuss in the early stage as it's more flexible.

Some open questions regarding this PR:

  1. Do we want to have the ability to expose the secret value, it's kind of visible when using localStorage connector but may be hidden for in-memory connector?

Some proposals regarding this plugin:

  1. From what I have seen, looks like this plugin was created to host secrets for other plugins. Do we also want to let user to manager their own secrets?

  2. We should have the functionality to grant some API_KEY to be used in some notebooks' environment variable. This can be done once we implemented the feature to send the secrets to the kernel

This was referenced Apr 3, 2025
@brichet
Copy link
Collaborator

brichet commented Apr 3, 2025

Thanks @Jas0nch for updating the PR.

I opened #10 and #11 from you comments/questions.

Maybe we should wait for more visibility on the expected features of that project before moving forward with the UI component.

@Jas0nch
Copy link
Author

Jas0nch commented Apr 3, 2025

I agree with you. Let’s hold this PR for now

@Jas0nch Jas0nch closed this Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants