Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Extensions ignore --use-context and --config-file and get the current context's credentials

オープン
#738 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
70/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
cli

調査の方向性

Start in the extension dispatch path in src/cli.ts (around lines 341-354), where loadCfg() is called without the parsed --use-context, --config-file or --command-profile values, then follow buildContextEnv in src/extension/context.ts. Compare with the early config sniffing at src/cli.ts:150-206. Done when the reproduction commands print URL=http://b.example:9200 ARGS=x for both flag positions, and tests cover global flags before and after the extension name.

索引モデルが issue の本文から書いたものです。

説明

Summary

Extensions always receive the env for the config file's current_context, ignoring --use-context and --config-file. The extension dispatch path in src/cli.ts (lines ~341-354) calls loadCfg() with no options, so buildContextEnv (src/extension/context.ts) builds ELASTIC_ES_URL/ELASTIC_ES_API_KEY/etc. from the default context. The early config load at src/cli.ts:150-206 doesn't help here: it sniffs --use-context/--config-file/--command-profile, but extension dispatch never threads those values into loadCfg().

A related symptom: dispatch forwards process.argv.slice(3), so when a global flag comes before the extension name, the flag, its value, and the extension name all get passed to the extension as positional args.

Reproduction

Built dist/cli.js, using a fake HOME so nothing touches the real ~/.elastic:

R=/tmp/a22; mkdir -p $R/home/.elastic $R/ext
printf '#!/bin/sh\necho "URL=$ELASTIC_ES_URL ARGS=$*"\n' > $R/ext/run; chmod +x $R/ext/run
echo "[{\"name\":\"dumpenv\",\"source\":\"local:$R/ext\",\"path\":\"$R/ext\",\"entrypoint\":\"$R/ext/run\"}]" > $R/home/.elastic/extensions.json
cat > $R/cfg.yml <<'Y'
current_context: a
contexts:
  a: { elasticsearch: { url: "http://a.example:9200", auth: { api_key: "AAA" } } }
  b: { elasticsearch: { url: "http://b.example:9200", auth: { api_key: "BBB" } } }
Y
export HOME=$R/home ELASTIC_CLI_CONFIG_FILE=$R/cfg.yml
node dist/cli.js --use-context b dumpenv x
node dist/cli.js dumpenv --use-context b x
unset ELASTIC_CLI_CONFIG_FILE; node dist/cli.js --config-file $R/cfg.yml dumpenv x

Actual:

URL=http://a.example:9200 ARGS=b dumpenv x
URL=http://a.example:9200 ARGS=--use-context b x
URL= ARGS=/tmp/a22/cfg.yml dumpenv x

Expected: URL=http://b.example:9200 ARGS=x for the first two commands. The third should use cfg.yml and output ARGS=x.

Notes

This is a security concern as well as a correctness one. A user who runs --use-context staging to keep a tool away from prod still hands the extension the prod credentials. The root banner check (earlyConfig.value.banner) isn't part of this bug, because earlyConfig is loaded with the sniffed overrides. Open PR #718 (#700) doesn't change the extension dispatch path.

Acceptance criteria

  • Extension dispatch passes the parsed --use-context, --config-file and --command-profile values to loadConfig, and the extension env reflects the chosen context.
  • Global flags placed before the extension name are not forwarded to the extension as args.
  • Tests cover both flag positions.

Related

#512, #576, #700, #718


authored by Pi Coding Agent (Claude Opus 5.5)

主要言語
TypeScript
スター
49
フォーク
27
平均マージ
1日 15時間
マージ済み PR(30日)
73

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

elastic/cli のほかの issue

elastic/cli の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。