Support env for API key management

[Ooker]

Plugins sometimes need to access API, e.g. GitHub, Google, OpenAI. For security, the tokens need to be kept in an env file so that it can be gitignore’d. Some plugins, like Enveloppe, have their own env file. Is a global env file a good idea?

If the env an be outside of the vault folder so that it can be shared on multiple vaults, then it can be great.

[ariehen]

Please include the template when posting bug reports or feature requests. Thanks!

[Ooker]

Is this better? I didn’t use the template because I think it make the request unnecessarily lengthy. Also, why is it better on the help category and not the feature request one?

---

Use case or problem

Some plugins need access to APIs (e.g., GitHub, Google, OpenAI). To maintain security, API tokens are typically stored in an environment (env) file, which can then be ignored by version control using .gitignore. While some plugins, like Enveloppe, have their own dedicated env files, managing multiple env files across plugins can become cumbersome. A global env file could simplify token management and make it easier to use plugins across multiple vaults.

Proposed solution

Introduce a global env file that can be used by all plugins, stored outside of the vault folder. This would allow multiple vaults to share the same configuration, reducing redundancy and streamlining the management of API tokens. Each plugin could access the global file, eliminating the need for separate env files for every plugin.

Current workaround (optional)

Currently, plugins like Enveloppe have their own individual env files. Users need to manually manage these files, duplicating tokens across plugins and vaults, which can be inefficient and error-prone.

Related feature requests (optional)

Global Settings / Same settings, themes, and plugins across multiple vaults

I liked OP but want to emphasize this comment above: User-specific global settings and plugins Workspace settings and plugins that override global settings. Only the individual modified (different) settings should be stored i.e. don’t copy the entire user-specific json. Read both and the workspace json should contain only the overriding setting. Show in the UI which settings are modified in user/workspace Allow in the UI for the user to reset a setting to app/user default i.e. what Visual S…

[WhiteNoise]

I am gonna move this thread to developers and api.

[pjeby]

There are many ways to save API tokens in an Obsidian plugin:

• Plugin settings (possibly w/obfuscation); Pros: syncs to mobile, easy access. Con: can’t be easily shared across vaults
• Local storage; Pros: not too hard to access, accessible between vaults. Con: extra coding complexity, especially if you want different keys in different vaults.
• OS-level Environment; Pros: easy to access, never synced, global to all vaults. Cons: hard for users to configure, never synced, and global to all vaults.

I wouldn’t think of .env files as being in the top three - they are among other things, only really usable in desktop (on mobile you can’t access arbitrary files), hard for users to create and edit, and add more complexity to your plugin to access them, especially in arbitrary locations.

Finally, if you are only supporting desktop and no sync to other machines, you can potentially also use Electron safeStorage encryption to encrypt keys while they are saved in settings or localStorage. (But then you can only access them on the same desktop where you encrypted them.)