Support environment variable placeholders in configuration files

Aberta
  • Algo errado?
#1,667 1 comentário 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 2 dias

@waldekmastykarz já está trabalhando nisso.

Desde 31/10/2026.

  • #2031 de @waldekmastykarz — aberto

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
52/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
csharp
Domínio
cli, tooling

Direção de pesquisa

Comece rastreando o carregamento da configuração para devproxyrc.json e os arquivos de configuração de plugins; depois, leia ProxyUtils.ReplaceVariables, IProxyConfiguration.Env e o caminho de substituição existente de MinimalPermissionsPlugin. Verifique como os valores de ambiente e a seção de configuração env são representados antes de decidir onde a resolução deve ocorrer. O trabalho estará concluído quando os placeholders ${VAR_NAME} forem resolvidos de forma consistente nos arquivos de configuração mostrados sem exigir um script de reescrita, com cobertura para placeholders incorporados, como a URL do issuer.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

work in progress

Summary

Dev Proxy config files (devproxyrc.json and plugin config files like CrudApiPlugin API files) don't support environment variable placeholders. This means values that vary per environment — like Entra app client IDs or tenant IDs — must be hardcoded in config files, or users need to write scripts to patch them before running Dev Proxy.

Example: the workaround today

In the da-ristorante-api-devproxy-entra sample, we need to inject ENTRA_APP_CLIENT_ID and ENTRA_APP_TENANT_ID into the CrudApiPlugin API files. Because Dev Proxy doesn't support this, the sample includes a Node.js script that reads .env.local and rewrites the JSON config files before each run.

The config file looks like this:

{
  "entraAuthConfig": {
    "audience": "<ENTRA_APP_CLIENT_ID>",
    "issuer": "https://login.microsoftonline.com/<ENTRA_APP_TENANT_ID>/v2.0"
  }
}

And the script manually replaces those placeholders with values from env files. This works but adds friction — extra tooling, an extra build step, and mutated config files that can accidentally get committed.

What I'd like to see

Support for environment variable references in config files, for example:

{
  "entraAuthConfig": {
    "audience": "${ENTRA_APP_CLIENT_ID}",
    "issuer": "https://login.microsoftonline.com/${ENTRA_APP_TENANT_ID}/v2.0"
  }
}

When Dev Proxy loads a config file, it would resolve ${VAR_NAME} placeholders against environment variables (or the env config section).

Why this seems feasible

Dev Proxy already has closely related infrastructure:

  • Path tokens: ~appFolder and ~dataFolder are resolved via ProxyUtils.ReplacePathTokens when loading config/plugin paths
  • @dynamic tokens: used in mock responses and rate limiting headers, resolved at runtime
  • ProxyUtils.ReplaceVariables: a general-purpose string replacement utility that replaces variable references in a string given a dictionary of values
  • IProxyConfiguration.Env: the proxy configuration already exposes a Dictionary<string, string> Env property
  • MinimalPermissionsPlugin already uses ProxyUtils.ReplaceVariables(fileContents, ProxyConfiguration.Env, v => $"{{{v}}}") to resolve {VAR} placeholders in OpenAPI spec files

The pattern is already proven in plugins — it just needs to be applied when loading configuration files too.

Benefits

  • No more wrapper scripts to inject environment-specific values
  • Config files stay clean and committable (no secrets, no environment-specific values)
  • Consistent with how other tools handle this (Docker Compose, Azure Pipelines, GitHub Actions, etc.)
  • Works naturally with .env files and CI/CD environments
Linguagem predominante
C#
Estrelas
838
Forks
90
Merge médio
2d 11h
PRs com merge (30d)
62

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de dotnet/dev-proxy

Todas as issues de dotnet/dev-proxy

Issues semelhantes

Mais issues de C#

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.