Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Passing Default Headers #266

Closed
nsankaranarayanan opened this issue May 29, 2017 · 11 comments
Closed

[Feature Request] Passing Default Headers #266

nsankaranarayanan opened this issue May 29, 2017 · 11 comments

Comments

@nsankaranarayanan
Copy link

nsankaranarayanan commented May 29, 2017

Overview

  • `Insomnia Version: v5.1.0
  • `Operating System: Windows 10 Professional
  • `Summary: Need a way to pass a default set of headers for all requests under a folder.
    Currently I am passing the headers like Accept, Authorization, etc for each one of the requests separately. Is there a way to add them at the folder level, so that I don't have to pass them every time.

The objective is to avoid passing it every time and rather the request inherit the parent folder's settings.
It would also be useful to override the parent folder's headers if the request had the same header.

Thanks

@gschier gschier changed the title Passing Default Headers [Feature Request] Passing Default Headers May 29, 2017
@gschier
Copy link
Contributor

gschier commented May 29, 2017

Hi @nsankaranarayanan. There's no way to do this at the moment, but it's a highly-requested feature.

I've been trying to think of a clean way to do this for a while, and just had an idea.

The headers tab could include include a <select> dropdown at the bottom and let the user choose an environment variable to include headers from. The environment variable could be a simple key-value object and could be included in either the global/sub/folder environment.

Here's what an example environment might look like:

{
  "headers": {
    "Accept": "application/json",
    "Authorization": "token 1234"
  }
}

I think I'll play around with this today and see if I can get something working.

@nsankaranarayanan
Copy link
Author

I am open to the idea though I want to emphasize one thing. You currently have a good way of implementing substitution parameters. While implementing this don't lose that.

@gschier
Copy link
Contributor

gschier commented May 29, 2017

The existing functionality would be preserved, but there would be an additional option to extend an environment variable. I'm thinking something like this:

image

@wonderbeyond
Copy link

Waiting for release.

@gschier
Copy link
Contributor

gschier commented Nov 4, 2017

Closing this one in favor of #447

@gschier gschier closed this as completed Nov 4, 2017
@gschier
Copy link
Contributor

gschier commented Nov 7, 2017

If anyone is still wanting this, I created a simple plugin to do it. It uses a special environment variable to pull header configuration from: https://www.npmjs.com/package/insomnia-plugin-default-headers

@wonderbeyond
Copy link

wonderbeyond commented Nov 8, 2017

Yes, Initially, I want such a method to pass authorization header, however I always copy from existing request as walkaround.

And maybe this can be a first-class function but not a plugin.

Previously, I always copy from existing request, but often with something I don't want.

@wonderbeyond
Copy link

@gschier and you've mismatched insomnia in the plugin name.

@gschier
Copy link
Contributor

gschier commented Nov 8, 2017

@wonderbeyond for authentication, you probably want to follow #447
Also thanks. I fixed the typo.

@wonderbeyond
Copy link

@gschier Thanks! #447 is awesome idea!
I've been always copying existing requests, waiting you save me.

@m3c-ode
Copy link

m3c-ode commented May 18, 2022

I've tried using the plug-in, but it does not seem to create any UI changes for me to define my default header for all my collection. How should it be used?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants