Closed drventure closed 1 week ago
Yes, I am working on an UI where headers can be specified at the collection level. Hoping to have this shipped over the weekend.
Anyway, the idea is that you can define a set of Header elements in an environment and have those elements automatically populate the headers for the requests using that environment.
Can you describe a use case here with a real world example, There may be alternate ways of achieving this in Bruno. Something like this where you want the headers to use a different access key based on the env
See Secrets Management in Bruno
.env
DEV_AWS_ACCESS_KEY_ID=123
DEV_AWS_SECRET_ACCESS_KEY=123
PROD_AWS_ACCESS_KEY_ID=123
PROD_AWS_SECRET_ACCESS_KEY=123
environments/dev.bru
vars {
AWS_ACCESS_KEY_ID = {{process.env.DEV_AWS_ACCESS_KEY_ID}}
AWS_SECRET_ACCESS_KEY = {{process.env.DEV_AWS_SECRET_ACCESS_KEY}}
}
environments/prod.bru
vars {
AWS_ACCESS_KEY_ID = {{process.env.PROD_AWS_ACCESS_KEY_ID}}
AWS_SECRET_ACCESS_KEY = {{process.env.PROD_AWS_SECRET_ACCESS_KEY}}
}
And then use {{AWS_ACCESS_KEY_ID}}
and {{AWS_SECRET_ACCESS_KEY}}
inside your header
Related: https://github.com/usebruno/bruno/issues/409#issuecomment-1751453778
Yes, that's basically the idea. I my case, I have several different nested environments , one for each service I generally connect to to test. But each service requires a slightly different set of headers (don't ask :( ) Anyway, Nested env vars are the first step to addressing the issue but the main issue is that, since virtually all the calls to a particular service require identical headers, the idea of global headers is that you'd define an env var like so
.env
DEV_AWS_ACCESS_KEY_ID=123 DEV_AWS_SECRET_ACCESS_KEY=123
PROD_AWS_ACCESS_KEY_ID=123 PROD_AWS_SECRET_ACCESS_KEY=123
environments/dev.bru
vars { HEADERS = { AWS_ACCESS_KEY_ID = {{process.env.DEV_AWS_ACCESS_KEY_ID}} AWS_SECRET_ACCESS_KEY = {{process.env.DEV_AWS_SECRET_ACCESS_KEY}} } } environments/prod.bru
vars { HEADERS = { AWS_ACCESS_KEY_ID = {{process.env.PROD_AWS_ACCESS_KEY_ID}} AWS_SECRET_ACCESS_KEY = {{process.env.PROD_AWS_SECRET_ACCESS_KEY}} } }
and then you wouldn't have to enter anything into the HEADERS definition of a particular request. The fact that the HEADERS var is defined would automatically pull all of the elements of that var into the header for the request, like this
AWS_ACCESS_KEY_ID: {{process.env.PROD_AWS_ACCESS_KEY_ID}} AWS_SECRET_ACCESS_KEY: {{process.env.PROD_AWS_SECRET_ACCESS_KEY}}
Or something similar.
Basically, the idea is that you want to avoid having to copy and paste multiple header entries over and over for each request you define.
I hope that makes sense. It really does save a ton of time when you're putting together numerous requests, or making changes to header definitions of already defined requests.
Real-world example: an API I use needs a secret value sent in an HTTP header.
It would be great if I could declare (once, at the collection or folder level) that the x-mycompany-secret
header is sent on all requests.
The header value would probably be an environment secret.
I am working on collection level headers and scripts. Looking forward to release it tomorrow - https://github.com/usebruno/bruno/issues/334
For my understanding, this should be implemented, so we can close the ticket? Thanks again @helloanoop!
Closing this issue as the latest version of Bruno now supports Collection Level Headers
One other really nice aspect of Insomnia is "Global Headers".
There are implemented via a plugin, so maybe that model would make sense for Bruno too?
Anyway, the idea is that you can define a set of Header elements in an environment and have those elements automatically populate the headers for the requests using that environment.
Of course, the headers can be nested because of the fact they're defined in an environment, so nested headers can be defined with overrides at each level.