usebruno / bruno

Opensource IDE For Exploring and Testing Api's (lightweight alternative to postman/insomnia)
https://www.usebruno.com/
MIT License
25.23k stars 1.15k forks source link

Global Headers? #453

Closed drventure closed 1 week ago

drventure commented 11 months ago

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.

helloanoop commented 11 months 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.

helloanoop commented 11 months ago

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

drventure commented 11 months ago

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

Headers in request

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.

edbrannin commented 11 months ago

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.

helloanoop commented 11 months ago

I am working on collection level headers and scripts. Looking forward to release it tomorrow - https://github.com/usebruno/bruno/issues/334

nikischin commented 2 weeks ago

For my understanding, this should be implemented, so we can close the ticket? Thanks again @helloanoop!

helloanoop commented 1 week ago

Closing this issue as the latest version of Bruno now supports Collection Level Headers