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

Đang mở
  • Có gì không ổn?
#5,080 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
authentication

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
16.5k
Fork
1.5k
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của triggerdotdev/trigger.dev

Tất cả issue của triggerdotdev/trigger.dev

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.