I am new to Tavern API Testing and I am trying to pass a token as an env var (my api is written in nodejs). Here is my code
test_name: POST /logs
marks:
- post_logs
stages:
- name: post a log entry
request:
url: "{host:s}:{port:d}{base_path:s}/investigate/api/{version:s}/logs"
method: POST
headers:
Authorization: "Basic {tavern.env_vars.TOKEN}"
content-type: application/json
params:
body:
log: blahblahblah
response:
status_code: 204
My problem is I do not know where to add my token in env_vars? is it a special .env tavern file I need to add?
You need to define your token as an environment variable in the shell from which you run Tavern tests. There are many ways to define an environment variable. My examples use Bash syntax; you may need to look up the right syntax if you are using a different shell. For testing with a short-lived token, you can define an environment variable right on the same command line that runs the tests:
TOKEN="some_token_value" py.test
The problem with that approach is that the token value gets saved in your shell command history, which is not a good security practice. A better approach is to create a file to store confidential data like a long-lived authentication token. The file name does not matter, but a common choice is .env. The contents of the file should be:
export TOKEN="some_token_value"
If using Git, add .env to your .gitignore file so that credentials are never added to your repo. Source the .env file to set the environment variables prior to running tests:
source .env
py.test
Environment variables only last as long as the shell session, so you need to source the file every time you open a new shell (terminal window or SSH session).
Related
Actually I have a nodejs express app with its config file for params like host, port, JWT token, DB params and more.
The question is if it could have sense to keep those params directly on environment variables (whitout any config file) and acces them without the need of do the "require" for config in all components and modules.
All examples I see uses a config file, probably something about security or memory?
config file is usually for setting the default values for your environment variables,
which is needed when you are writing the test cases and need to use default values or mock values,
and also you will have all the env variables at one place which is better management.
so if you have an environment variable x,
in config file you can keep it as
config.x = process.env.x || 'defaultVale or mockValue'
A config file lets your very quickly set the entire environment of a machine - eg S3 buckets, API urls, access keys, etc. If you separate these into separate process.env.VARIABLE then you would need to set each of these...for which you would likely make a script...and now you have an environment file again!
To access environment variables you can use process.env.VARIABLE in your nodejs code (is always a string), as long as the variable is set before the process is started.
Another possibility is using an .env files in nodejs. I think you have to npm install dotenv in your application. Ideally different instances (dev, prod....) have its own .env file, and you dont have to call require("dotenv") every time if you want to access the environment variable. Call it in the very beginning i.e) in app.js and you can access the environment variable in any of the sub-files.
I have a nodeJS application. In the .env file I have specified
AUTH_USERNAME=admin
AUTH_PASSWORD=password
I now want to add separate admin accounts for more users. What is the best/accepted way to attack this? I have tried searching on the topic but, understandably, it gets very complicated very quickly - can anyone give me a dummies guide for my possibilities here?
Thanks.
The solution in your case without changing approach where to store credentials is use separator in environment variables. Example with , as separator:
#.env file or environment variables values
AUTH_USERNAMES=admin,admin2
AUTH_PASSWORDS=password,password2
//your code
require('dotenv').config(); // for reading .env file or how do you use that
const adminsUsernames = process.env.AUTH_USERNAMES.split(',');
const adminsPasswords = process.env.AUTH_PASSWORDS.split(',');
Please, think about change .env file to database or config.json file. Maybe, this list will help you:
obviously, you received downvotes on your question, because of non-common approach where to store credentials. Common approach is store credentials at database.
according The Twelve Factors manifest environment variables are
used for configuration whole application.
.env is used for simplification setting environment variables during local development. In production DevOps setup env vars on the server.
netlify command-line lets you specify the access_token either through ~/.config/.netlify or the -A switch.
However I was wondering whether it'll be accepted through the ./netlify.toml config file.
In the docs there seem to be fields that suggest it might:
[context.production]
environment = { ACCESS_TOKEN = "super secret", NODE_ENV = "8.0.1" }
[context.deploy-preview.environment]
ACCESS_TOKEN = "not so secret"
But when I try it gives the error "No access token found. Please login." (from debug logs)
So, is it possible to set the access_token through ./netlify.toml file, and if so what am I doing wrong?
If not, what do the ACCESS_TOKEN mentioned in the docs actually do, and how are they different from the access_token found in ~/.config/.netlify file?
So, is it possible to set the access_token through netlify.toml file, and if so what am I doing wrong?
The netlifyctl command line sets up the access_token in a config file not an environment variable, so the ACCESS_TOKEN environment variable would not be used by the netlifyctl command at the time of this answer.
If not, what do the ACCESS_TOKEN mentioned in the docs actually do, and how are they different from the access_token found in ~/.config/netlify file?
The ACCESS_TOKEN mentioned in the docs is just an example of how to set an environment variable for use in a script or build process at the time of a deploy on netlify. These two are not one in the same and have nothing to do with each other in this case. In theory, you could use the environment variable to build a script to run the netlifyctl -A using the environment variable to pass the access token to the command.
NOTE: Do not put secret tokens into your netlify.toml file or .env files of a public repository for Netlify. In fact, be careful when using secret keys on public repositories in Netlify. These keys could be exposed by a commit or pull request by someone else or by accident. There is an explanation here of how to build a .env file to create environment variables from "Build Environment Variables" section for use in build scripts in a private repository.
I have some information in my react native app which is considered sensitive. It is the accessKey and secretKey for my S3 instance.
Is there a command line tool to add these variables to the keychain, rather than having to hard code them into the code.
It is currently working with credentials in the code, but if it's possible I'd like to take them out.
Ideally, what I'm looking for are some global variables that I can set from the command line and then use in my application code. For instance run: $ ACCESS_KEY = 1234567890 from the command line, and then in my code I can just get the ACCESS_KEY variable.
Thanks,
I'm trying to run a number of api calls using dredd and api blueprint to test a site. I would like to run the tests on circleCI, as there are Selenium tests running in the same place. Each transaction needs to be accompanied by two tokens, which are set as cookies in the headers. Ideally, these would be set in the dredd.yml file. When running on a local machine, if I replace ACCESS_TOKEN and REFRESH_TOKEN with the actual values, the test runs as expected.
circle.yml:
test:
override:
- dredd
dredd.yml headers
header: ['Cookie: access_token=ACCESS_TOKEN; refresh_token=REFRESH_TOKEN']
Where ACCESS_TOKEN and REFRESH_TOKEN get replaced by the actual values set in circleCI's environment variables. I have also tried:access_token=$[ACCESS_TOKEN], access_token=$["ACCESS_TOKEN"] and access_token=$ACCESS_TOKEN. None of these are being replaced in the headers for the first api call.
The header looks like: {"Content-Type":"application/json; charset=utf-8","User-Agent":"Dredd/1.4.0 (Darwin 14.5.0; x64)","Cookie":" access_token=$ACCESS_TOKEN; refresh_token=$REFRESH_TOKEN"}
I am new to yaml files, so I'm probably missing something basic, but I did search around for a while. The hooks file is written with node.js, so I don't think the ruby/rails help will be useful here. If I am missing anything in the question don't hesitate to let me know.
YAML is a data representation language, not a template language (or template processor, for that matter). While an individual program might support loading environment variables or additional parameters named in the configuration, the YAML parser (probably, unless it's a custom module) isn't what's injecting them. While skimming the dredd docs I don't see any references to environment variables or parameters, it may be worth creating an issue on the project and starting a discussion with the developers to see if this is supported.
I can think of a number of ways to solve your specific problem, but they all involve additional tools to render the YAML with your variables injected. Perhaps the easiest solution for your case is to set environment variables in the CircleCI web configuration (NOT version-controled circle.yml). Then, set up a pre-build step, where the YAML configuration is generated. To do this, wrap the YAML in a BASH script, with the YAML document contained inside of it as a here-doc.
#!/bin/bash
# ACCESS_TOKEN and REFRESH_TOKEN are injected by CircleCI
cat <<EOF > config.yml
---
header: ['Cookie: access_token=${ACCESS_TOKEN}; refresh_token=${REFRESH_TOKEN}']
EOF
Then run the rest of your job normally, perhaps deleting the configuration file or restoring it from version control before any artifacts are created to avoid the leakage of your credentials.
The better way to work with headers is by Hook files setting headers before each request. As you are using Node.js, try set Node environment variables:
var hooks = require('hooks');
hooks.beforeEach(function(transaction) {
transaction.request.headers.Cookie =
'access_token=' + ACCESS_TOKEN +
'; refresh_token=' + REFRESH_TOKEN;
}