Folder / Workspace Inheritance

Comments (18)

Gregory Schier

OP·2 years ago

Hmm, yes folder-based inheritance could be a nice feature. I have some ideas for how to do overrides like this that will probably come inside a larger change. I can see wanting to change settings/values inside a folder, environment, or even workspace (eg. app theme)

Gregory Schier

OP·2 years ago

Ian.H ·2 years ago

Seconded on this one. Being able to set this at a global level is pretty important for my workflow.

Just.Chola ·a year ago

I’d love to attempt building a plugin for this, but I have so much on my plate.
and i haven’t seen any documentation on what Yaak values are exposed to us for a plugin .
However Global Headers are a total must

Rob Cresswell·a year ago

I’m curious how others are finding Yaak feasible to use without this feature. Is there something I’m missing? Even our small API has a couple dozen endpoints so far, and setting auth headers on each one is not something I’m going to tell my colleagues to do, as much as I’d love to recommend Yaak.

Konstantin Ilchenko·a year ago

I was able to make a (very rough) proof of concept of plugin for this. Unfortunately it’s unrealistic to talk about publishing it, because the current state of plugins API just doesn’t have everything needed to at least achieve feature parity with corresponding plugin for Insomnia. Things that API is currently missing:

A more general plugin type for enriching/altering the request. In my PoC I use the `AuthenticationPlugin` type. It’s the only type which allows to alter request headers, but it wasn’t really designed for this, therefore some restrictions apply:
- You have to specifically select “Global headers“ as the Auth mode. Moreover it has to be done per request
- As a consequence of a previous bullet, you can’t combine Global headers with any other Auth mode.
There is no way to obtain the current workspace and/or its environment. Because of this, in the PoC I’ve just hardcoded the headers list
It’s pretty hard to debug the code. console.log doesn’t print anything in the inspector, `debugger;` statement doesn’t break – it seems like the process executing the plugin code is pretty well isolated
yaakcli codegen is lagging behind with dependencies, installing API typings of v0.2.x while the current version is 0.4.1

It works though. I may return to make a better version if/when the API has everything needed.

Leaving it here in case somebody wants to play:

import { 
    CallHttpAuthenticationRequest, 
    CallHttpAuthenticationResponse, 
    Context, 
    HttpHeader, 
    PluginDefinition,
} from '@yaakapp/api';

type Args = CallHttpAuthenticationRequest;
type GlobalHeaders = Promise<CallHttpAuthenticationResponse>;

const registry: { [key: string]: HttpHeader[] } = {
    default: [
        { name: 'x-test-header', value: 'default' },
    ],
    demo: [
        { name: 'x-test-header', value: 'overriden' },
    ]
}

export const plugin: PluginDefinition = {
    authentication: {
        name: 'global-headers',
        label: 'Global headers',
        shortLabel: 'Global headers',
        args: [{
            name: 'section',
            type: 'select',
            options: Object.keys(registry).map(x => ({ label: x, value: x })),
            optional: true,
            defaultValue: 'default',
        }],
        async onApply(ctx: Context, args: Args): GlobalHeaders {
            const headers = [
                ...registry['default'],
                ...(args.values.section === 'default' ? [] : registry[args.values.section as string]),
            ];
            
            return { setHeaders: headers };
        },
    },
};

If you want to run it:

generate a plugin with yaakcli generate,
update @yaakapp/api to at least v0.4.1
edit the registry variable
build it with yaakcli build (or yaakcli dev)
import the plugin to yaak
select “Global headers“ auth mode for your request and select a section (or leave the default one)

Jamie Macey·a year ago

This is seriously the one thing that keeps me coming back to Postman: I can set up authentication at the folder level, and it’s inherited automatically for every new request I create.

I’m working on a reasonably API-heavy product, and we do internal stakeholder demos every 2 weeks, and an app where I need to care about the difference between “new request” that needs auth configured again from env variables and “duplicate request” that copies the current setup is just giving me papercuts every time I need to diagnose auth failures. (Is it permissions flags in the app, or the tool letting me down?)

Being able to manage some defaults for the whole workspace instead of each toplevel folder would be great as well.

Mickael

·a year ago

This is also the main feature that keeps me from migrating. No way I set up all my auth again on every single request. Auth and headers per folder/worksapce

Jacob Enemark·a year ago

This is quite high on my wishlist as well. Working on a project which relies heavily on http communication, this is a must.

Gregory Schier

OP·a year ago

This is going to be the next big(ish) project I start after the next release!

Please post your real use cases here, to help shape what the feature looks like.

Dinei Rockenbach

·a year ago

Nice to hear you are looking into this Greg! I work at a (fairly) big company and we are currently using Postman across the company. I want to propose a full migration to Yaak, but I can’t really build a case without this feature.

To give you some context: we use some APIs with custom authentication based on hashing headers, request body, and some secret keys. I wrote a plugin that implements this authentication method, and it turned out very nicely. However, configuring this custom authentication for every HTTP request is a real PITA.

So, what I expect from this feature is to be able to configure the authentication for all requests for a folder and all requests inside this folder would inherit the authentication configured in the folder. Moving a request from one folder to another would mean it now inherits the authentication from the new parent folder. This is very similar to what Postman offers (the default authentication for requests is “Inherit auth from parent”).

Gregory Schier

OP·a year ago

Great to see you’re making use of plugins! It sounds like your description of this feature is exactly what I plan to implement 👍🏼

Gregory Schier

OP·a year ago

Check out 2025.3 Beta 1 for auth / header inheritance!

https://yaak.app/blog/2025.3.0-beta.1

It seems like most people wanted this to be for auth and headers, so that’s what I’m shipping first. I’ve made a new ticket for settings inheritance that you can follow here:
https://feedback.yaak.app/p/request-level-settings

Dinei Rockenbach

·a year ago

Thanks for releasing this to Beta already Greg! I quickly tested it out in Beta and found one (important) bug: environment variables are not being replaced in folder-level configurations.

For the headers part, I configured one header for a folder using an environment variable as the value and it didn’t replace the value.

I also tested using a custom authentication plugin configured at the folder level. I have a plugin that provides a custom authentication and includes one user-provided value as a header in the request. I configured this custom auth in the folder-level using an environment variable to fill some values, and apparently the plugin receives the variable name in the Yaak format (i.e., ${[ VARIABLE ]} ) instead of the actual value.

This works correctly if the auth and header are configured at the request level.

Gregory Schier

OP·a year ago

Oof! Thanks for the report. Should be working now in Beta 4

Dinei Rockenbach

·a year ago

Seems to be working indeed, thanks Greg! I will let you know if I find anything else in the following days.

Gregory Schier

OP·a year ago

Awesome, thanks for the confirmation!

Gregory Schier

OP·a year ago

https://yaak.app/blog/2025.3.0