Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support environment variable placeholders in configuration files

Aperta
  • Qualcosa non va?
#1,667 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
csharp
Ambito
cli, tooling

Direzione di ricerca

Inizia tracciando il caricamento della configurazione per devproxyrc.json e i file di configurazione dei plugin, quindi leggi ProxyUtils.ReplaceVariables, IProxyConfiguration.Env e il percorso di sostituzione esistente di MinimalPermissionsPlugin. Verifica come sono rappresentati i valori dell’ambiente e la sezione di configurazione env prima di decidere dove debba avvenire la risoluzione. Il lavoro è completo quando i segnaposto ${VAR_NAME} vengono risolti in modo coerente nei file di configurazione mostrati senza richiedere uno script di riscrittura, con copertura per i segnaposto incorporati come l’URL dell’issuer.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs peer review

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
Lingua principale
C#
Stelle
833
Fork
90
Merge medio
18h 41m
PR unite (30g)
45

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/dev-proxy

Tutte le issue di dotnet/dev-proxy

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.