Insomnia: Strategy for avoding plain text passwords in environment?

[alexbjorlig]

Is it possible to avoid plain-text passwords in the "Manage Environments" section of Insomnia?

• Make the tokens non-readable?
• Would it be possible to maybe reference the environment on the machine?
• Maybe using a .env file?
• Integrate with 1Pasword manager - or a different password manager?

[develohpanda]

Great question!

Would it be possible to maybe reference the environment on the machine?

You can install insomnia-plugin-system-env to achieve this. Plugins to the rescue! 🎉

In addition, there are a couple more options that you have, ordered in increasing effort:

• Private environments, while these _are_ plain-text, a private environment will never be exported or synced
• Use a prompt template tag
• Custom plugin to integrate with env file or a password manager

Prompt

Use a prompt template tag with the "mask text" and "default to last value" options selected

There are several options in the template tag modal to control persistence of the value. You may choose to set a storage key, which will clear the value from storage once the app is closed. Direct downside with the prompt: it will prompt each time the value is needed.

Custom plugin

Additionally, while there are currently no plugin APIs for _manipulating_ an Insomnia environment itself, it is possible to create a plugin that will fetch a variable from a specified file on the filesystem or from a password manager. This plugin can be exposed via custom template tags. It should be fairly straightforward to make one, similar in principle to the system-env plugin. 👀

PS: we have discussed directly supporting system environment variables within the last week. I like this option in particular because it would allow for CI workflows with the CLI (inso) in a seamless and secure manner. The CLI currently doesn't cater for plugins so it can't use the one I just linked, yet. 😢)

[alexbjorlig]

Thanks for the answer. A custom plugin that would get the secrets from a .env file or a password manager would be epic. What needs to be done for the exposure of a plugin API to manipulate the environment?

[develohpanda]

Just to clarify, a plugin that reads from a .env file or a password manager _does not_ need the exposure of a plugin API to manipulate the environment. It would just operate as a standalone template tag, to fetch a variable using x plugin.

However, off the top of my head, exposing an API to actually manipulate an Insomnia environment _should_ also be trivial. If you'd like to use this API feel free to propose a design of how you might use it and we can work towards adding it. But for the above plugins^ you should be able to make do without it.

For instance, the .env file path can be an Insomnia environment variable, if you have different env files for local vs staging vs production.

[alexbjorlig]

For instance, the .env file path can be an Insomnia environment variable, if you have different env files for local vs staging vs production.

My biggest dream 😂 - because in our team we all share an .env file, needed for our code project to connect to services. Would be 🔥 if Insomnia hooks into this. When I find the time, I will give it a try 😅

[develohpanda]

You've given me inspiration to build something as well as I can absolutely see a use case for it, having used .env.local, .env.staging files in the past.

I do think this belongs in a plugin rather than the application itself, as there is a use case for standard Insomnia environments as well. Will ping here if I end up patching something together. 😄 EDIT: by all means, give it a go as you'll likely get to it before I do. Would love to see what you make!

[develohpanda]

@alexbjorlig there is a comment in the linked issue above, referring to a plugin that can consume env files! 🎉 https://github.com/Kong/insomnia/issues/1883#issuecomment-596269972

[bongosway]

For instance, the .env file path can be an Insomnia environment variable, if you have different env files for local vs staging vs production.

My biggest dream 😂 - because in our team we all share an .env file, needed for our code project to connect to services. Would be 🔥 if Insomnia hooks into this. When I find the time, I will give it a try 😅

@alexbjorlig https://www.npmjs.com/package/insomnia-plugin-dotenv is now published. Please give it a test run and let me know of any bugs or enhancements.

Kind Regards

[alexbjorlig]

Thanks for putting together a plugin - however it's the first Insomnia plugin I tried. Where do I provide the path for the env file?

[bongosway]

Thanks for putting together a plugin - however it's the first Insomnia plugin I tried. Where do I provide the path for the env file?

In the template screen:

1. Select dotenv from the dropdown.
2. Click to choose .env, your system dialog will open up to enable you to select a file
3. Enter the variable name you need to retrieve.
4. Live Preview should now show you the value assigned to that variable
5. Click done.
6. Your screen should like the below.

[alexbjorlig]

That works - and pretty impressive this is possible with just 35 lines of code - good job 🥳

However, if I understand this correctly the "limitations" of the environment API in insomnia means that if I have 31 secrets I have to define 31*3=93 environment variables - because a plugin can't create an environment on my behalf (dev/stage/prod)?

(I'm not saying it's a showstopper, it's just error-prone since my teammates will have to the same?)

[develohpanda]

@bongosway amazing! I'm excited to try this out. 💯

@alexbjorlig technically yes. You'll notice that in the template tag modal, there is a cog on the right hand side, meaning the entry can itself come from an Insomnia environment variable.

What you can do, is map each variable one to one against your env file in the base insomnia environment. Then specify an envFilePath in the three sub environments, eg env.local, env.staging, env.production. Lastly, when consuming the dotenv plugin, reference the envFilePath variable instead of hard-coding it. There might be a gotcha with how base and sub environments work, though.

Give it a go, I'll also put an example workspace together and share it with you tomorrow!

[alexbjorlig]

@bongosway amazing! I'm excited to try this out. 💯

@alexbjorlig technically yes. You'll notice that in the template tag modal, there is a cog on the right hand side, meaning the entry can itself come from an Insomnia environment variable.

What you can do, is map each variable one to one against your env file in the base insomnia environment. Then specify an envFilePath in the three sub environments, eg env.local, env.staging, env.production. Lastly, when consuming the dotenv plugin, reference the envFilePath variable instead of hard-coding it. There might be a gotcha with how base and sub environments work, though.

Give it a go, I'll also put an example workspace together and share it with you tomorrow!

Thanks! It's already much better than hard-coding the secrets multiple places

[develohpanda]

Here is an example workspace, but note, need @bongosway to review this PR and deploy an update of the plugin to support it. I found a case that didn't work during testing, and created a PR against the plugin.

Note, you can create the dev/stage/prod sub environments as _private_ environments, so that the machine-specific file-path will not sync for each user. 😄

[bongosway]

Here is an example workspace, but note, need @bongosway to review this PR to support it. I found a case that didn't work during testing, and created a PR against the plugin.

Done. v1.0.1 released

Many thanks @develohpanda