bug: RBAC adapter makes distinct one-time public JWTs share an environment-key fingerprint

オープン
  • 何か問題がありますか？
#5,080 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

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

調査の方向性

Start by reading internal-packages/rbac/src/bearerCredentials.ts where the public JWT result and oneTimeUse are produced, then apps/webapp/app/services/routeBuilders/apiBuilder.server.ts where authentication.apiKey is populated, and apps/webapp/app/services/apiAuth.server.ts where getOneTimeUseToken hashes it. Follow the trigger route apps/webapp/app/routes/api.v1.tasks.$taskId.trigger.ts to see how the token reaches the run service. A fix is done when distinct public JWTs produce distinct one-time-use identifiers while private-key and non-one-time paths stay unchanged, backed by regression tests.

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

説明

Summary

At current main commit ba9448974f4b026efa62f2cb447c076d9a25b04f, authenticateRequestForApiBuilder() sets authentication.apiKey to result.environment.apiKey, including for an authenticated public JWT. The task trigger route then calls getOneTimeUseToken(authentication), which hashes authentication.apiKey.

Consequently, distinct one-time JWTs for the same environment produce the same one-time-use identifier: the environment key is hashed instead of the presented JWT. Once that identifier is present on a run, a fresh JWT can be rejected as already used.

Source path

  1. Bearer resolver returns the authenticated environment plus oneTimeUse for a public JWT.
  2. apiBuilder adapter places the environment key in authentication.apiKey.
  3. One-time-use helper hashes that field.
  4. Trigger route passes the resulting value to the run service. The engine converts a oneTimeUseToken uniqueness conflict to the already-used-token error.

Minimal illustration

This dependency-free example illustrates the collision; the source-extracted regression harness described below additionally executes the real functions.

const assert = require('node:assert/strict');
const { createHash } = require('node:crypto');
const environment = { apiKey: 'NONSECRET_OFFLINE_ENVIRONMENT_KEY' };

// Models the adapter after successful authentication of each distinct JWT.
function bridge(presentedJwt) {
  return { type: 'PUBLIC_JWT', oneTimeUse: true, apiKey: environment.apiKey };
}
function oneUseId(auth) {
  return createHash('sha256').update(auth.apiKey).digest('hex');
}

const jwtA = 'synthetic-distinct-jwt-a';
const jwtB = 'synthetic-distinct-jwt-b';
assert.notEqual(jwtA, jwtB);
// Fails: these must be distinct, but both hash the environment key.
assert.notEqual(oneUseId(bridge(jwtA)), oneUseId(bridge(jwtB)));

Source-extracted verification

Using Node 22.22.3 and TypeScript 5.9.3, an offline harness extracts the actual authenticateRequestForApiBuilder, getOneTimeUseToken and presentedBearerToken functions from that pinned commit and strips their types. Successful RBAC authentication is the fixture; the adapter and hashing functions are real upstream code. Two differently signed synthetic JWTs for one synthetic environment collide with the pristine adapter. No provider requests or real credentials are involved.

A proposed adapter correction passes eight checks: the baseline collision; distinct fresh-token fingerprints; identical-token replay identity; a minimal uniqueness model; non-one-time behavior; unchanged private-key behavior; forwarded RBAC denial; and fail-closed handling of an absent bearer token. The uniqueness model uses a Set, not the full run-engine database; full upstream integration testing remains necessary.

Suggested correction

Preserve the presented bearer JWT in authentication.apiKey for a successfully authenticated publicJWT subject, while leaving other subject types unchanged. The existing presentedBearerToken(request) helper can supply it after RBAC succeeds. Fail closed if that value is absent. Do not remove one-time protection or widen scopes.

const publicJwt = result.subject.type === "publicJWT"
  ? presentedBearerToken(request)
  : undefined;
if (result.subject.type === "publicJWT" && !publicJwt) {
  return { ok: false, status: 401, error: "Invalid or missing public JWT" };
}
// In the existing authentication object:
apiKey: publicJwt ?? result.environment.apiKey,

Alternatively, carry the presented-token identity in a dedicated field and hash that explicitly. The candidate has not been deployed, and all authentication paths need maintainer review before accepting it.

Hosted symptom and limits

A separate isolated Development check using SDK/CLI 4.8.1 and a verified V2 worker returned HTTP 422 with the one-time-token-used error on a fresh one-use token's only recorded caller submission. No new run appeared in the subsequent task/time-filtered read. Connection validation used a different read-only token. The caller stopped and did not retry.

This is consistent with the source defect, but we cannot attest which backend build processed that hosted request or its database state. We are not treating the local test as proof of a deployed fix. Related symptom report: #3780; a shared cause is not assumed.

Could you confirm whether the cloud task-trigger route uses this adapter and review the token identity passed to getOneTimeUseToken? The reproduction, regression tests and proposed patch are ready to share. No credentials, customer data, project IDs or run IDs are included here.

主要言語
TypeScript
スター
16.5k
フォーク
1.5k
平均マージ
1日 15時間
マージ済み PR（30日）
17

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

triggerdotdev/trigger.dev のほかの issue

triggerdotdev/trigger.dev の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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