X-Forwarded-User を信頼する切り替えが、デプロイ手順どおりに設定しても有効にならない

Start with apps/web/nuxt.config.ts, apps/web/server/utils/auth-config.ts, and DEPLOY-NEOSHOWCASE.md, then review the existing helper in apps/web/server/utils/auth-config.test.ts. The issue leaves six fixes and the smtpSecure and csv scope undecided, so first agree on the intended configuration behavior and security boundary. Done means the selected behavior is covered by regression tests and the deployment instructions consistently describe the working setting.

症状

DEPLOY-NEOSHOWCASE.md の「2-4. 環境変数」の表は NUXT_TRUST_FORWARD_AUTH の「値」欄に 1 と書いています。このとおりに設定しても AuthConfig.trustForwardAuth は偽のままで、X-Forwarded-User は読まれません。NeoShowcase の Soft member-auth が有効になりません。

原因

原因が 2 つ重なっており、デプロイ手順は 1 つ目だけを扱っています。3 つ目の候補として調べたものをこの節の末尾に書きます。根拠は Nuxt 4.x の https://nuxt.com/docs/4.x/guide/going-further/runtime-config(2026-09-20 に取得)です。apps/web/package.json は nuxt に ^4.5.2 を指定しています。

1 つ目は名前です。apps/web/nuxt.config.ts は trustForwardAuth の既定値を process.env['CHECKIN_TRUST_FORWARD_AUTH'] から取ります。

Setting the default of runtimeConfig values to differently named environment variables (for example setting myVar to process.env.OTHER_VARIABLE) will only work during build-time and will break on runtime.

同じドキュメントは、実行時に上書きできるのは NUXT_ で始まり _ でキーと大文字小文字の変わり目を区切った大文字の環境変数だけだと定めており、trustForwardAuth に対応するのは NUXT_TRUST_FORWARD_AUTH です。「2-4. 環境変数」の前書きは、このうち NUXT_ 接頭辞で渡すことを既に書いています(_ で大文字小文字の変わり目を区切るという後半は書かれていません)。

2 つ目は型です。ここがデプロイ手順に書かれていません。

Environment variable values are automatically cast to their JavaScript type using destr. For example, NUXT_MY_VAR=4848e0 becomes the number 4848. To keep a value a string, the environment variable value itself must contain literal double quotes: in a .env file, write NUXT_MY_VAR='"4848e0"'; when setting the variable directly (in a shell, Dockerfile, or hosting dashboard), make sure the quotes are part of the value and not stripped by the shell (for example NUXT_MY_VAR='"4848e0"' node .output/server/index.mjs).

apps/web/server/utils/auth-config.ts の resolveAuthConfig は rc.trustForwardAuth === '1' という厳密等価演算子による文字列との比較で真偽を決めます。この変換を行う applyEnv を [email protected]([email protected] を使います)で直接呼んで測ったものが次の 2 つの表です。以下、表にある組み合わせの真偽は表の行で示し、値の一覧を文章で書き直しません。表に無い値を文章で挙げる場合は、既定値がどれのときかを必ず添えます。同じ変数の値が既定値によって真にも偽にもなるので、変数の値だけを並べると条件が落ちるためです。

表 1 は現在の宣言のときの結果です。既定値の列は nuxt.config.ts の process.env['CHECKIN_TRUST_FORWARD_AUTH'] ?? '' がビルド時に解決した値で、結果の列は JSON.stringify の出力です。行の記号は下の「直す対象」から参照します。再現する手順は下の「確かめ方」にあります。

行	ビルド時の既定値	NUXT_TRUST_FORWARD_AUTH	結果	型	=== '1'(現状)	String(…) === '1'(手 1)
A1	'1'	1	1	number	偽	真
A2	'1'	未設定	"1"	string	真	真
A3	''	1	1	number	偽	真
A4	''	"1"(二重引用符を含む 3 バイト)	"1"	string	真	真
A5	'1'	"1"(二重引用符を含む 3 バイト)	"1"	string	真	真
A6	''	'"1"'(単引用符を含む 5 バイト)	"'\"1\"'"	string	偽	偽
A7	'1'	0	0	number	偽	偽
A8	'1'	空文字	""	string	偽	偽
A9	'1'	false	false	boolean	偽	偽
A10	''	未設定	""	string	偽	偽

表 2 は、既定値を真偽値で宣言したときの結果です。手 4 と退けた候補 2 と退けた候補 3 がこの表を使います。

行	ビルド時の既定値	NUXT_TRUST_FORWARD_AUTH	結果	型	真偽だけを見る(退けた候補 2)	=== true(手 4)
B1	false	未設定	false	boolean	偽	偽
B2	false	1	1	number	真	偽
B3	false	true	true	boolean	真	真
B4	false	0	0	number	偽	偽
B5	false	false	false	boolean	偽	偽
B6	false	空文字	""	string	偽	偽
B7	false	no	"no"	string	真	偽
B8	false	off	"off"	string	真	偽
B9	false	disabled	"disabled"	string	真	偽
B10	false	2	2	number	真	偽
B11	false	-1	-1	number	真	偽
B12	true	未設定	true	boolean	真	真
B13	true	1	1	number	真	偽

有効にしようとしたときに起こりうる組み合わせは 3 つあり、結果が分かれます(どちらも設定しない場合は A10 で、偽です)。「2-4. 環境変数」の表に載っているのは NUXT_TRUST_FORWARD_AUTH だけですが、同じ文書の「方針サマリ」と「認証の仕組み」は CHECKIN_TRUST_FORWARD_AUTH=1 を挙げているので、どちらか一方だけを設定することも、両方を設定することもありえます。

• 「2-4」の表だけに従った場合(ビルド環境に CHECKIN_TRUST_FORWARD_AUTH が無く、NUXT_TRUST_FORWARD_AUTH=1)。A3 に当たり、既定値は空文字のままで実行時に数値の 1 が入るので偽です。これが症状の主な経路です。
• 両方を設定した場合。A1 に当たり、ビルド時に文字列の 1 が焼き込まれても実行時の数値の 1 がそれを置き換えるので偽です。
• CHECKIN_TRUST_FORWARD_AUTH=1 だけを設定し、NUXT_TRUST_FORWARD_AUTH を設定しなかった場合。A2 に当たり、焼き込まれた文字列の 1 がそのまま残るので真になります。

つまり、CHECKIN_TRUST_FORWARD_AUTH=1 を与えた配備では、「2-4」の表の行を入れると A1 で偽になり、入れないと A2 で真になります。手順に従うと有効にならず、従わないと有効になる、という逆転が起きています。

3 つ目の候補として、useRuntimeConfig() に event を渡していないことを調べました。resolveAuthConfig は event を渡さずに呼びます。同じページの "Server Routes" の節は「Giving the event as argument to useRuntimeConfig is optional, but it is recommended to pass it to get the runtime config overwritten by environment variables at runtime for server routes.」と書いています。ただし [email protected] の dist/runtime/internal/config.mjs を読むと、event の無い useRuntimeConfig() が返すのはモジュールの評価時に一度 applyEnv を通した値なので、プロセスの起動前に設定された環境変数はこの配備でも届きます。これは実装を読んで得た結論で、ドキュメントは逆を推奨しています。上の表も applyEnv を直接呼んで測ったもので、useRuntimeConfig() 越しには測っていません。nitropack の版が変われば、この結論は変わりえます。

影響範囲

destr の変換が崩すのは === '1' という比較の形ではなく、「runtimeConfig の値は文字列である」という前提そのものです。apps/web/server/utils/ の auth-config.ts・billing-config.ts・jomon-config.ts の 3 ファイルが、いずれも値の出どころを「runtimeConfig, which Nuxt types as string」と書いたコメントを持ち、String() で包むことと ?? '' を付けることを dead code だとしています。同じディレクトリの config-value.ts は positiveNumberOr(value: string, fallback: number) と宣言し、auth-config.ts の csv(value: string) は value.split(',') を呼びます。

誰が何を誤るか。この 3 ファイルを読む人は、runtimeConfig から来る値を文字列として扱ってよいと読み、型を確かめる記述を足しません。実際には、環境変数で上書きされた値の型は destr が決めます。NUXT_ACCOUNTANT_TRAQ_IDS に数字だけの値(たとえば 123)を入れると applyEnv は数値の 123 を置き、csv の value.split(',') が TypeError: value.split is not a function を投げます。測ったものです(手順は下の「確かめ方」)。

既存のテストではこの型の取り違えを表現できません。apps/web/server/utils/auth-config.test.ts の runtimeConfig(overrides: Record<string, string>) と resolveWith は、useRuntimeConfig の返り値を文字列だけで組み立てます。applyEnv が置く数値・真偽値・配列を渡すには、このヘルパの型から変える必要があります。回帰テストを足す場合はそこが起点になります。

=== '1' と同じ形の比較は、resolveAuthConfig の中にもう 1 つあります。rc.smtpSecure === '1' です。rc.mailerDriver === 'smtp' も同じ形ですが、こちらは driver: rc.mailerDriver === 'smtp' ? 'smtp' : 'log' という 2 分岐に使われていて、一致しない値はすべて log に落ちます。destr の変換がこの分岐の結果を変えるのは、変換後の値がちょうど文字列の smtp になるときだけです。smtp は applyEnv を通しても同じ文字列のまま返り、log・sendgrid も同じで、数字だけの値である 1 は数値の 1 になって log に落ちます(いずれも測りました)。数え方と測り方は下の「確かめ方」にあります。

現在はどちらの値になっているか

AuthConfig.trustForwardAuth が偽のとき、apps/web/server/utils/auth.ts の buildRequestContext は applyForwardedIdentity を通さず、転送されたヘッダ(x-forwarded-user と x-showcase-user)を読みません(同じ関数は isCsrfValid 経由で x-csrf-token を読むので、ヘッダ一般を読まないわけではありません)。apps/web/server/routes/verify-email/confirm.get.ts も同じ条件で分岐します。転送されたヘッダを信頼しない側になっているので、なりすましの経路が開くわけではありません。apps/web/server/routes/login.get.ts は偽のとき自前の traQ OAuth に回りますが、「2-4. 環境変数」の表は NUXT_TRAQ_* を「不要」としているので、その表のとおりの配備では /login が壊れて気付けます。

直す対象

コードとデプロイ手順の両方にあります。次の 6 つの手があり、どれを採るかは決めていません。どの手でも併せて決める必要があるものが 2 つあります。rc.smtpSecure === '1' を同じ扱いにするかと、影響範囲に挙げた csv が数値を受け取って TypeError を投げることをこの issue で直すかです。後者は trustForwardAuth の真偽とは別の欠陥で、6 つの手はどれもこれを直しません。

前提。どの手も、この切り替えを有効にするためのものです。DEPLOY-NEOSHOWCASE.md の「4. 注意・落とし穴」と #36 が書いているとおり、X-Forwarded-User を信頼してよいのは、プロキシを経由せずコンテナへ直接到達できない配備に限ります。直接到達できる環境で有効にすると、ヘッダを偽装した任意のなりすましが通ります。

• 手 1。受け取り側を String(rc.trustForwardAuth) === '1' にする。表 1 の右端の列のとおり、真になるのは A1〜A5 です。上に挙げた 3 つの組み合わせ(A1・A2・A3)がどれも真になるので、デプロイ手順を 1 文字も変えずに済みます。A6〜A10 は偽のままです。影響範囲に挙げた auth-config.ts のコメントが String() を dead code だとしているので、そのコメントも同時に直す対象になります。測った範囲での限界は下の「確かめ方」に書きます。
• 手 2。「2-4」の表の「値」欄を "1"(二重引用符 2 文字を含む 3 バイト)にする。ドキュメントが挙げている方法で、直すのはデプロイ手順の表だけになります。A4(既定値が空文字のとき)と A5(焼き込みがあるとき)のどちらでも真になります。ただし上の引用の後半が言うとおり、引用符が値に残ることを入力先ごとに確かめる必要があります。シェルや .env ファイルの書き方である '"1"' をそのまま書いて単引用符まで値に入ると A6 になり、偽のままです。
• 手 3。ビルドを走らせる環境で CHECKIN_TRUST_FORWARD_AUTH=1 を与える。この手だけでは効きません。現状の === '1' の列で見ると、既定値が '1' になる行のうち真なのは A2 と A5 だけで、「2-4」の表のとおり NUXT_TRUST_FORWARD_AUTH=1 も設定すると A1 になって偽だからです(右端の手 1 の列で見ると A1 も真になりますが、それは手 1 を併せて採った場合の話です)。代償は 2 つあります。「2-4」の表からその行を外すことが要ることと、無印の変数を効かせる手なので DEPLOY-NEOSHOWCASE.md の 3 箇所と両立しないことです。§2-4 の見出しが「(すべて NUXT_ 接頭辞)」、その前書きが「無印だとビルド時の空値が焼かれて効かない」、§5 のトラブルシュートが「原因: 無印 env はビルド時の空値が焼かれている。対処: NUXT_ 接頭辞で設定(§2-4)」と書いています。
• 手 4。nuxt.config.ts の既定値を真偽値の false で宣言し、受け取り側を rc.trustForwardAuth === true にする。表 2 の右端の列のとおり、真になるのは B3 と B12 です。代償は 2 つあります。「2-4」の表の 1 は B2 で偽になるので表の「値」欄を true に直すことが要ることと、既定値から process.env['CHECKIN_TRUST_FORWARD_AUTH'] を外すことになるので CHECKIN_TRUST_FORWARD_AUTH が何の効果も持たなくなることです。後者で直す対象になる記述は 4 箇所あります。この変数を名指ししている「方針サマリ」と「認証の仕組み」の 2 箇所に加えて、*_TRUST_FORWARD_AUTH=1 というワイルドカードで両アプリをまとめている「3. 相互配線とデプロイ後の確認」と「4. 注意・落とし穴」の 2 箇所も、Checkin 側の正しい値が true になるので片側が誤りになります。
• 手 5。受け取り側で runtimeConfig を経由せず process.env['CHECKIN_TRUST_FORWARD_AUTH'] を直接読む。process.env から読む値は destr を通りません。Node.js の公式ドキュメント(https://nodejs.org/api/process.html、2026-09-20 に取得)は process.env を「The process.env property returns an object containing the user environment. See environ(7).」と書いています。この文は値の型を述べていないので、型の根拠は参照先の environ(7) です。environ(7)(https://man7.org/linux/man-pages/man7/environ.7.html、2026-09-20 に取得)は「The variable environ points to an array of pointers to strings called the "environment".」と定め、続けて「By convention, the strings in environ have the form "name=value".」と書いています。前者は環境が文字列の配列であることを無条件に述べ、後者はその文字列を name=value の形に区切ることを規約として述べています。値はこの文字列の一部なので、環境変数として渡された値は文字列です。この配備で実際にそうなることは、CHECKIN_TRUST_FORWARD_AUTH=1 を付けて子プロセスを起動し、typeof process.env['CHECKIN_TRUST_FORWARD_AUTH'] が string で値が "1" になることで確かめました(手順は下の「確かめ方」)。この 1 件の測定は仕様の裏付けであって、一般則の根拠は上の 2 つのドキュメントです。なお同じ Node.js のページが process.env へ JS から代入した場合について述べている規則は別の話で、そこには「This behavior is deprecated.」が付いています。このリポジトリにも同じ書き方はあります。apps/web/server/routes/dev/login.get.ts の defineEventHandler が process.env['CHECKIN_DEV_LOGIN'] !== '1' で分岐します。ただしこれは先例になりません。同ファイルの doc comment は import.meta.dev がビルド時にリテラルの false に置き換わると書いており、#73 も同じ理由でこの経路を対象から外しています。本番のバンドルで実行時の process.env の読み取りが効くことは、このリポジトリでは確かめていません。上に引いた「別名の環境変数を既定値にすると実行時に壊れる」は runtimeConfig の既定値についての記述なので、process.env を直接読む形には当たりません。代償は 2 つあります。設定の読み出しが runtimeConfig に揃っている形から外れること、「2-4」の表の NUXT_TRUST_FORWARD_AUTH の行が効かなくなるので、その行を CHECKIN_TRUST_FORWARD_AUTH に置き換える必要があることです。
• 手 6。起動時に落とす。apps/web/server/plugins/validate-config.ts は既に本番で stripeSecretKey の欠落を見て起動を止めています。同じ場所で rc.trustForwardAuth が真偽を決められる値かを見れば、黙って偽になる代わりに起動時に分かります。検証の対象を広げること自体は #65 が扱っています。他の手と併せて採る手で、単独では切り替えを有効にしません。

退けた候補 1。上に引いた 1 つ目の引用(別名の環境変数について述べたもの)の直後で、同じドキュメントは「It is advised to use environment variables that match the structure of your runtimeConfig object.」と勧めています。この助言のとおり、既定値を process.env['NUXT_TRUST_FORWARD_AUTH'] に改名するか、既定値から process.env を外して NUXT_TRUST_FORWARD_AUTH だけで渡す形にしても、症状は直りません。1 つ目の原因(名前)は解消しますが、2 つ目(型)がそのまま残るからです。前者はビルド環境に NUXT_TRUST_FORWARD_AUTH があれば A1、無ければ A3 に当たり、後者は既定値が空文字に固定されるので A3 です。どちらの行でも実行時に applyEnv が destr を通すので数値の 1 になり、=== '1' は偽です。

退けた候補 2。nuxt.config.ts の既定値を真偽値の false で宣言し、受け取り側は真偽だけを見る形(同じファイルの enableUnsafeMutations がこの形です)は、fail-open するので採りません。表 2 の「真偽だけを見る」の列で真になるのは B2・B3・B7〜B13 で、B7・B8・B9 は no・off・disabled を設定した行です。切り替えを止めるつもりで off と書いた運用者が、転送されたヘッダの信頼を有効にします。退けているのは真偽だけを見る受け取り側であって、真偽値で宣言すること自体ではありません。=== true にすればこの問題は起きないので、手 4 として別に挙げています。

退けた候補 3。既定値を process.env['CHECKIN_TRUST_FORWARD_AUTH'] === '1' という真偽値で宣言し、受け取り側を === true にする形は、手 4 の 2 つ目の代償(CHECKIN_TRUST_FORWARD_AUTH が効かなくなること)を消せますが、採りません。ビルド環境にこの変数があれば既定値は true になり、NUXT_TRUST_FORWARD_AUTH が未設定なら B12 で真になります。しかし「2-4」の表のとおり NUXT_TRUST_FORWARD_AUTH=1 も設定すると B13 になって偽なので、手 3 と同じくその行を外すことが要ります。加えて、既定値を別名の環境変数から導く形はそのまま残るので、1 つ目の原因(名前)は解消しません。

退けた候補 4。nuxt.config.ts の runtimeConfig.nitro.envPrefix を CHECKIN_ にして、実行時に上書きできる名前を CHECKIN_TRUST_FORWARD_AUTH にする形も、症状は直りません。このキーは、上に引いた Nuxt の runtime-config のページにも、Nitro の設定のページ(https://v2.nitro.build/config、2026-09-20 に取得)にも現れません。この段落が依拠しているのは実装と版([email protected] と @nuxt/[email protected])です。下の「確かめ方」が書いているとおり NUXT_ を与えているのは @nuxt/[email protected] で、同じ箇所は nuxt.config.ts の runtimeConfig.nitro をその後に展開するので、そこに書いた値が上書きします。変えれば 1 つ目の原因(名前)は解消します。しかし applyEnv は同じように destr を通すので、CHECKIN_TRUST_FORWARD_AUTH=1 は数値の 1 になり、=== '1' は偽のままです(既定値が '1' でも '' でも偽になることを測りました)。加えて、このキーは runtimeConfig のすべての値に効くので、NUXT_MAIL_HASH_SECRET をはじめ「2-4. 環境変数」の表の行がすべて改名を要します。

関連

• #36(X-Forwarded-User の信頼境界を担保すると決める)。あちらは境界をどう担保するかを決める issue で、この issue は切り替えが設定どおりに効かないことを扱います。
• #65(起動時の設定検証が stripeSecretKey だけ)。上の「起動時に落とす」はこの issue の範囲です。#65 の本文は AuthConfig が読む値として trustForwardAuth を既に挙げています。
• #72 の T7(設定の読み出しは自作を続ける)。この issue が影響範囲を広げた層についての現行の決定です。上に挙げた手はいずれも自作の読み出しの中で閉じるので、T7 の結論を変えるものではありません。T7 が再検討するとしている zod による検証へ置き換える場合は、この issue の症状もそちらで扱うことになります。

確かめ方

リポジトリの記述は main の c81574a で確かめたものです。リポジトリのルートで次を実行します。

# 名前と比較、runtimeConfig の値を文字列として扱っている記述
grep -n 'trustForwardAuth' apps/web/nuxt.config.ts apps/web/server/utils/auth-config.ts
grep -n 'enableUnsafeMutations' apps/web/nuxt.config.ts apps/web/server/utils/auth.ts
grep -n 'mutationsEnabled' packages/api/src/orpc.ts
git grep -n 'which Nuxt types as' -- apps/web/server/utils
grep -n 'positiveNumberOr' apps/web/server/utils/config-value.ts
grep -n 'split' apps/web/server/utils/auth-config.ts

# event を渡さない useRuntimeConfig() の呼び出し
git grep -n 'useRuntimeConfig' -- apps/web/server

# 同じ形の比較が他にあるか
git grep -nE "rc\.[a-zA-Z]+ === '" -- apps/web/server/utils

# デプロイ手順の記述
grep -n 'TRUST_FORWARD_AUTH' DEPLOY-NEOSHOWCASE.md

「同じ形の比較」の数え方が当てているのは apps/web/server/utils だけで、apps/web/server の残り(plugins と routes)は範囲の外です。拾うのは、rc で終わる名前に付けたプロパティを単引用符で囲んだリテラルと === で比べている行のうち、プロパティ名が英字だけのものです。

拾いすぎます。rc\. は行のどこにでも一致するので、src.trustForwardAuth === '1' や myrc.smtpSecure === '1' のように rc で終わる別の名前も拾います(そういう行を書いたファイルを作って確かめました)。c81574a の apps/web/server/utils に該当する行はありませんが、返った行が rc そのものかは目で見る必要があります。

拾い漏らします。rc.snake_case === '1' のように名前に _ や数字を含むものは、条件に当てはまっても拾いません(c81574a の apps/web/server にそういう名前のプロパティは 1 つもありませんが、増えれば数えられなくなります)。次の 4 つも拾いません。分割代入で取り出してから比べているもの(apps/web/server/plugins/validate-config.ts の const { stripeSecretKey } = useRuntimeConfig() と stripeSecretKey === '')、ヘルパの引数に渡してから中で比べているもの(apps/web/server/utils/jomon-config.ts の version(rc.jomonApiVersion))、!== で比べているもの、二重引用符で囲んだリテラルと比べているものです。

手 1 の String(rc.trustForwardAuth) === '1' が真になるのは、表 1 では A1〜A5 です。表に無い値についても同じ手順で測れます。既定値が空文字のとき、NUXT_TRUST_FORWARD_AUTH に 1.0・ 1・1 ・1 を入れるといずれも数値の 1 になって真、JSON の配列として解釈される [1] も String([1]) が "1" になるので真、01・0x1 は文字列のまま残るので偽です。既定値が '1' のときは変数を設定しなければ真で、これは表の A2 です。測っていない値については分かりません。

型の変換は、インストール済みの nitropack の applyEnv を直接呼ぶと再現できます。nitropack は推移的な依存なので、パッケージの位置を find で求め、選んだパスを出力に印字させています(同じ版のディレクトリが複数ある場合、head -1 がどれを選ぶかは列挙の順に依存するためです)。

prefix と altPrefix の出どころは 2 段です。prefix の NITRO_ は [email protected] の dist/runtime/internal/config.mjs にあるリテラルです。altPrefix の NUXT_ は同じファイルには無く、そこは _inlineRuntimeConfig.nitro.envPrefix ?? process.env.NITRO_ENV_PREFIX ?? "_" と書かれています。NUXT_ が入るのは @nuxt/[email protected] の dist/index.mjs が envPrefix: "NUXT_" を与えるからです。

NITRO=$(find node_modules/.pnpm -maxdepth 1 -type d -name "[email protected]_*" | head -1)
[ -n "$NITRO" ] || { echo "[email protected] が見つかりません。測ったのはこの版です。別の版で確かめる場合は -name の版を読み替えてください" >&2; exit 1; }
echo "# 使ったパス: $NITRO"
echo "# destr: $(node -p "require('fs').readFileSync('$NITRO/node_modules/destr/package.json','utf8').match(/\"version\": \"[^\"]+\"/)[0]")"
echo "# 環境から来た値の型"
CHECKIN_TRUST_FORWARD_AUTH=1 node -e 'const v=process.env["CHECKIN_TRUST_FORWARD_AUTH"]; console.log(JSON.stringify(v), typeof v)'
node --input-type=module -e '
import { pathToFileURL } from "node:url"
const { applyEnv } = await import(pathToFileURL(process.argv[1] + "/node_modules/nitropack/dist/runtime/internal/utils.env.mjs"))
const opts = { prefix: "NITRO_", altPrefix: "NUXT_" }
const K = "NUXT_TRUST_FORWARD_AUTH", DQ = String.fromCharCode(34), SQ = String.fromCharCode(39)
const show = (decl, env) => {
  if (env === null) delete process.env[K]; else process.env[K] = env
  const o = { trustForwardAuth: decl }
  applyEnv(o, opts)
  const v = o.trustForwardAuth
  console.log(JSON.stringify(decl), JSON.stringify(env), "->", JSON.stringify(v), typeof v,
              "eq1=" + (v === "1"), "String(v)eq1=" + (String(v) === "1"),
              "strictTrue=" + (v === true), "truthy=" + Boolean(v))
}
console.log("# 上の表")
for (const r of [["1", "1"], ["1", null], ["", "1"], ["", DQ + "1" + DQ], ["1", DQ + "1" + DQ],
                 ["", SQ + DQ + "1" + DQ + SQ], ["1", "0"], ["1", ""], ["1", "false"], ["", null]]) show(r[0], r[1])
console.log("# 表 2: 既定値が真偽値のとき")
for (const r of [[false, null], [false, "1"], [false, "true"], [false, "0"], [false, "false"], [false, ""],
                 [false, "no"], [false, "off"], [false, "disabled"], [false, "2"], [false, "-1"],
                 [true, null], [true, "1"]]) show(r[0], r[1])
console.log("# String(...) === 1 の限界(既定値が空文字のとき)")
for (const e of ["1", "1.0", " 1", "1 ", " 1 ", "[1]", "01", "0x1"]) show("", e)
console.log("# 退けた候補 4: envPrefix を CHECKIN_ にした場合")
const optsC = { prefix: "NITRO_", altPrefix: "CHECKIN_" }
for (const decl of ["1", ""]) {
  process.env["CHECKIN_TRUST_FORWARD_AUTH"] = "1"
  const o4 = { trustForwardAuth: decl }
  applyEnv(o4, optsC)
  const v = o4.trustForwardAuth
  console.log("既定値=" + JSON.stringify(decl), "->", JSON.stringify(v), typeof v, "eq1=" + (v === "1"))
}
console.log("# runtimeConfig の値を文字列として扱っている箇所")
const o2 = { accountantTraqIds: "" }
process.env["NUXT_ACCOUNTANT_TRAQ_IDS"] = "123"
applyEnv(o2, opts)
console.log("accountantTraqIds ->", JSON.stringify(o2.accountantTraqIds), typeof o2.accountantTraqIds)
const csv = (value) => value.split(",")
try { csv(o2.accountantTraqIds) } catch (e) { console.log("csv:", e.name + ": " + e.message) }
console.log("# mailerDriver に置いた値の型")
for (const e of ["smtp", "log", "sendgrid", "1"]) {
  process.env["NUXT_MAILER_DRIVER"] = e
  const o3 = { mailerDriver: "log" }
  applyEnv(o3, opts)
  console.log(JSON.stringify(e), "->", JSON.stringify(o3.mailerDriver), typeof o3.mailerDriver)
}
' "$NITRO"