importing secrets or sensitive variables

[chrisjlee]

Is it possible if i could import variables from a different file? I'd like to be able to import variables from another file so that they won't be stored in git.

e.g:

@import {{password}} from './secrets' @import {{authtoken}} from './secrets'

this way i can .gitignore this folder

Or is there a way to get environment variables from the CLI? I guess i'm asking for something similar to #252

[kenbellows]

Big +1 to this. It would be really cool if I could store the entire JSON config for a domain in an external file and simply specify the path to that file within "rest-client.certificates" instead of a JSON object, which should be pretty easy to detect as well. Something like this:

{
    // ...
    "rest-client.certificates": {
        "example.com": "/home/myname/secrets/certInfo/example.com.json"
    }
    // ...
}

The contents of ".../example.com.json" should just be the object that you would otherwise put in the config, e.g.:

{
    "pfx": "/home/myname/certs/mycert.p12",
    "passphrase": "iamsupercool"
}

This would be super handy, both for security and because it would allow more easily reusing credentials across domains by simply referring to the same JSON file.

[cloudrkt]

+1 This would be great. We would prefer passwords and other sensitive data outside the working directory included from an external source. Maybe hook it up to a password vault or keychain type of store?

[borekb]

For anyone reading this:

• 182 is a similar suggestion, maybe a bit simpler as it would import files entirely instead of specific variables from them.

• A workaround is to use system variables, like this:

@authToken = {{$processEnv AUTH_TOKEN}}

GET https://example.com
Token: {{authToken}}

The AUTH_TOKEN can be put to keychain (as mentioned by @cloudrkt), e.g., via onyxraven/zsh-osx-keychain, in which case the .bashrc can look like this:

export AUTH_TOKEN=$(keychain-environment-variable AUTH_TOKEN)

[sruthicp]

For anyone reading this:

• 182 is a similar suggestion, maybe a bit simpler as it would import files entirely instead of specific variables from them.

• A workaround is to use system variables, like this:

@authToken = {{$processEnv AUTH_TOKEN}}

GET https://example.com
Token: {{authToken}}

The AUTH_TOKEN can be put to keychain (as mentioned by @cloudrkt), e.g., via onyxraven/zsh-osx-keychain, in which case the .bashrc can look like this:

export AUTH_TOKEN=$(keychain-environment-variable AUTH_TOKEN)

Is this really working ? i didn't get the expected result using $processEnv. I am using environment variable for host url, but i am getting the following error Connection is being rejected. The service isn’t running on the server, or incorrect proxy settings in vscode, or a firewall is blocking requests. Details: RequestError: connect ECONNREFUSED 127.0.0.1:443.

but when i directly add the host url it is working. Not working with the $processEnv

I have added host variable in my .bashrc file

[borekb]

@sruthicps Did you fully restart VSCode (not just "reload window" but fully restart the app)? Environment variables are applied once, when VSCode starts, so that might be the reason.

Overall, yes, it works, we use this approach.

[sruthicp]

@borekb Sorry it was an issue with the shell i am using with vscode. When i changed the default shell, it works :) Thank you

[mchelen-gov]

another good option is to put credentials into a .env file which can be read using: {{$dotenv PASSWORD}} https://github.com/Huachao/vscode-restclient#system-variables

(remember to .gitignore this file to avoid committing it)

[fortinmike]

I would love the ability to import secrets from 1Password using the op CLI, without using any files (committed or not) as an intermediary.

A generic and super flexible way to do that (which could also support other password managers and other advanced workflows) would be to add "shell variables", e.g. something like this:

@password = {{$shell op item get ozg7wmrfzb24fsoxjp2vnjvviq --fields label=password}}

Where everything after $shell is a shell command that returns a string which is then assigned to the variable.

[kirill578]

@fortinmike I think that should be a small change. if you look at the PR above it might be 10 line change.

create a custom matcher for $shell, once matches execute the shell command and return the resolved value. TBH the documentation might be longer than the actual change.

https://github.com/Huachao/vscode-restclient/pull/366/files#src/utils/httpVariableProviders/systemVariableProvider.ts

I am thinking of going with Insomnia since there is a recent plugin for 1password.

[mfulton26]

You can use a git-ignored .env file:

https://github.com/Huachao/vscode-restclient/blob/a89f8bce1b5e3d5bd955f10916b0c101e20431d3/README.md#L630

Example .env file in the same directory as your .http file(s):

USERNAME=secret-username
PASSWORD=pass1234🤪

Example usage:

https://github.com/Huachao/vscode-restclient/blob/a89f8bce1b5e3d5bd955f10916b0c101e20431d3/README.md#L650-L664

[fortinmike]

@mfulton26 Thanks for the info. I assume this works (didn't test it), but the goal of the file-less approach I'm suggesting is to avoid storing plain-text passwords on the filesystem.

Using the theoretical shell variable feature, nothing would be stored in plain text anywhere. Running a request would trigger op, which would open the standard 1Password unlock dialog, then proceed with the request with variables filled in. Afterwards op should remember that we already gave access to those entries and not ask for unlock again.

[mfulton26]

@mfulton26 Thanks for the info. I assume this works (didn't test it), but the goal of the file-less approach I'm suggesting is to avoid storing plain-text passwords on the filesystem.

Using the theoretical shell variable feature, nothing would be stored in plain text anywhere. Running a request would trigger op, which would open the standard 1Password unlock dialog, then proceed with the request with variables filled in. Afterwards op should remember that we already gave access to those entries and not ask for unlock again.

ah, yes, I thought I was missing something; thank you