[1431] Auth middleware accepts expired JWT for 60s due to clockTolerance misconfiguration by ToryMic · Pull Request #1516 · Junirezz/YieldVault-RWA

ToryMic · 2026-09-30T03:44:37Z

📋 Description

Stacked PR. This branch is based on fix/1430-get-vaults-query-does-not-enforce-max-limit-and-allows-limit-100000-to-oom-the-api (PR #1515), so it carries that branch's two prerequisite commits: the repair of pre-existing main breakage and the #1430 fix. Review the diff of f2add84f..HEAD for this issue alone. Once #1515 lands, this PR rebases to a clean two-commit diff against main.

Goal

The auth middleware accepted an expired JWT for up to 60 seconds. One clockTolerance was applied across every time claim, but the tolerance exists to absorb nbf clock skew — it also let exp sit 60 seconds in the past. On top of that, nothing consulted the revocation list on the request path: /auth/logout returned 200 without revoking anything, so a stolen bearer token kept authorising POST /vault/:id/withdraw for the rest of its life, not just for a minute.

Closes #1431

Changes

Time claims — tolerance split, not widened (backend/src/auth.ts)

New assertTimeClaims() with TokenExpiredError / TokenNotYetValidError, plus an optional nbf claim on JwtPayload.
exp is checked with zero tolerance and is inclusive of the expiry second: RFC 7519 says a token is invalid at exp, so exp <= now is rejected. The old check was exp < now.
Only nbf / iat get CLOCK_SKEW_TOLERANCE_SECONDS (5s) of slack, which is what the tolerance is actually for — clock skew between the API pod and whatever minted the token.
Exported CLOCK_SKEW_TOLERANCE_SECONDS so the spec and the tests read the number from the implementation instead of hard-coding it.

Revocation list — real, shared, and consulted per request (backend/src/tokenRevocation.ts)

RevocationStore gains revokeWalletBefore() / isWalletRevokedBefore(): a per-wallet high-water mark instead of an id list, so /auth/logout-all is O(1) per wallet and cannot grow with session count. The marker never moves backwards — a later, broader revocation always wins.
revokeAllForWallet() previously deleted the matching records and recorded nothing, which silently un-revoked every token it touched. It now writes the wallet marker first.
The Redis store implements the new methods and falls back to its in-process store on error — including revokeAllForWallet, which used to return 0 and quietly do nothing.
The store is actually wired to Redis when REDIS_URL is set (the module docblock already claimed "Initialized by auth module based on deployment mode", but nothing did it). Without this, a logout handled by pod A is invisible to pod B and the stolen-token window re-opens.

Request path

requireAuth performs a revocation lookup on every authenticated request and answers 401 with code: 'TOKEN_REVOKED'. It fails closed — 503 AUTH_REVOCATION_UNAVAILABLE — if the store itself is unreachable, rather than downgrading to "token is fine".
POST /api/v1/auth/logout revokes the presented jti, and when a refreshToken is supplied, the whole refresh family too, so the session cannot be resurrected by rotation.
POST /api/v1/auth/logout-all writes the wallet marker and revokes every refresh family for the wallet.
OpenAPI: components.securitySchemes.bearerAuth documents the zero-tolerance exp, the 5s nbf skew and the per-request revocation check.

🔗 Type of Change

🐛 Bug fix (non-breaking change that fixes an issue)
🔒 Security improvement

🛡️ Risk Assessment

Risk Level

🟠 High: Core contract logic change, access control modification, financial accounting / share math

Access control is in scope, so the tier is High. See the blast-radius notes for why the effective change is narrow.

Blast Radius & Impact Analysis

Contract storage layout / data key migration involved
Value transfer, deposit/withdraw flow, or vault share calculation affected
External integration (Oracle, Soroban RPC, Bridge, Token contract) affected
Database schema migration or data backfill required
Breaking API or interface change affecting downstream clients
Zero blast radius (isolated tooling / documentation only)

Detailed Risk & Blast Radius Notes:

1. exp is now strict. A client whose clock is more than 5s ahead will see
   its own token rejected. Previously it would have been accepted (that
   was the bug), but the practical effect is that clock-skewed clients
   must re-authenticate rather than relying on the tolerance. This is the
   intended behaviour and is called out in the bearerAuth description.

2. exp == now is now rejected (was accepted). In practice a token's exp is
   now + 900, so nothing that worked before stops working; only a token
   checked in the exact second it expires changes result, from 200 to 401.

3. One revocation lookup per authenticated request. In-memory it is a Map
   read. With REDIS_URL it is one extra GET on a connection that is
   already used by the rate limiter and the token store, so the added
   round trip is on an existing connection and only on authenticated
   routes. Every authenticated endpoint already does at least one Prisma
   query, so the relative cost is small — but it is a real added latency
   for high-QPS authenticated routes, and RedisRevocationStore degrades
   to its in-process store on error rather than blocking.

4. requireAuth is now asynchronous past the signature check: it returns
   before calling next(). The one non-Express caller,
   authenticateTransactionExport in listEndpoints.ts, passes a synchronous
   next() and is unaffected. Express route usage
   (app.post('/auth/logout', requireAuth, handler)) is unaffected because
   Express ignores middleware return values.

5. /auth/logout and /auth/logout-all now perform revocation work. Both are
   already behind the `reads` rate-limit tier.

6. No on-disk data format changes; the revocation list is Redis / in-process.

🔄 Rollback Plan

Rollback Strategy & Feasibility

Clean Git Revert: Revertable with zero persistent state drift
Feature Flag / Circuit Breaker: Feature can be toggled off instantly without redeployment
Contract Upgrade Rollback: Tested rollback to previous contract WASM hash / implementation
Database Migration Revert: Reversible migration down-script tested and verified
Emergency Pause: Contract pause / freeze mechanism available to halt affected functions
Forward-Only / Irreversible: State migration cannot be cleanly reversed; emergency recovery runbook linked below

The SCHEDULED_TASK_ROLLBACK.md route is available for a partial rollback: revert only the wiring in index.ts (logout no longer revokes) while keeping the strict exp check, if the added revocation lookup is judged too expensive for a given deployment.

Rollback Trigger Criteria

- p95 latency on authenticated routes up more than 25ms attributable to the
  revocation lookup
- Redis revocation-store error rate above 1% (each error means a pod is
  silently serving from its in-process fallback)
- Legitimate clients reporting 401 TOKEN_REVOKED for tokens they did not
  log out (would indicate the wallet marker is over-broad)
- 401 rate on authenticated routes up more than 5% after deploy

Step-by-Step Rollback Procedure

git revert 9039e171 (or revert the tip commit).
No data rollback required: the revocation list is Redis keys under revocation:* with a TTL, and dropping them is safe — worst case a still-live token stays valid until its exp, which is the pre-fix behaviour.
If the Redis keys need clearing explicitly: redis-cli --scan --pattern 'revocation:*' | xargs -r redis-cli del.

⚡ Performance Impact

Performance & Resource Assessment

Backend API latency (p95/p99) and database query execution plans verified
Database indexing verified for newly queried columns (no table scans)
Memory allocation and leak checks verified (no memory leaks in long-running services)
No measurable performance impact (documentation, tests, or trivial changes)
Smart contract gas / compute units benchmarked (no regression > 5%, or justified below) — N/A, no Solidity touched
Frontend bundle size and Time to Interactive (TTI) verified — N/A, no frontend change

Performance & Gas Profiling Summary:

Per authenticated request, added:

  in-process : 1 Map.has()               (revocation list)
  Redis      : 1 GET revocation:token:{jti}
               (skipped entirely when no revocation exists? no — always
                issued, so it is one round trip on a connection already
                used by the rate limiter and the refresh-token store)

Removed:
  the 60s window during which expired tokens were still being accepted and
  doing full work downstream

Memory:
  per-token revocation entries are retained only until the token's own
  exp, at which point the strict expiry check rejects it anyway — the
  list is therefore bounded by (active sessions x access TTL), not by
  total lifetime volume. Wallet markers self-expire after 24h.

🔒 SECURITY REVIEW

Smart-contract sections (Reentrancy / CEI / Slither / gas limits) do not apply — this PR touches no Solidity.

Input validation: exp must be a finite number; a missing or NaN exp is rejected as a malformed payload rather than treated as "never expires".
Access control: requireAuth now performs two checks (cryptographic + revocation) and fails closed on store errors.
Authorization: revocation is scoped per token jti and per wallet, so revoking wallet A never affects wallet B (covered by a test).
Unbounded loop / DoS vector: the per-wallet marker is O(1) per wallet; per-token entries are TTL-bounded by the token's own exp.
TOCTOU: the revocation lookup happens after signature verification and before req.jwtPayload is set, so a handler can never observe a payload that has not been checked.

Option A: Fixed in This PR ✅

Vulnerability identified and resolved
Test case added to verify fix
Explain fix below:

The verifier used a single shared `clockTolerance` for all time claims, so
`exp` was accepted 60s in the past. Separately, `requireAuth` did not
consult the revocation list at all, and `/auth/logout` revoked nothing —
so "logout" was purely cosmetic.

Fixed by:
  1. splitting the tolerance — 0s on `exp`, 5s on `nbf`/`iat` only;
  2. making the revocation list real (wire Redis, make
     revokeAllForWallet record instead of delete) and wiring logout /
     logout-all to it;
  3. checking the list on every authenticated request, failing closed.

📝 Testing

Functional Testing

Unit tests added/updated for changes
Integration tests passing
End-to-end (E2E) tests passing — no frontend surface changed
Manual testing completed and documented below

cd backend
npx prisma generate
npx jest --runInBand
# Test Suites: 93 passed, 93 total
# Tests:       1371 passed, 1371 total

npm run lint          # 0 errors (pre-existing warnings only)
npm run build         # tsc, 0 errors
npm run generate:openapi && git diff --exit-code openapi.json

Security Testing

Access control test: unauthorized request rejected — a revoked token gets 401 TOKEN_REVOKED on the next request; a token from another wallet is unaffected
Boundary / edge-case test: exp == now (rejected), exp == now + 1 (accepted), exp == now - 59 (rejected — the exact case the old 60s tolerance allowed), nbf == now + 5 (accepted), nbf == now + 6 (rejected), missing / NaN exp (rejected)
Fail-closed test: the revocation store's Redis path is exercised with a client whose every command rejects, asserting the in-process fallback still enforces revocation

Test Coverage

All new code paths have test coverage
Security-critical paths have comprehensive test cases — backend/src/__tests__/jwtExpiryAndRevocation.test.ts, 29 tests

Specifically covering the issue's acceptance criteria:

exp strict with 0 tolerance, verified via a manual check — assertTimeClaims(payload, now) with a frozen nowSeconds; plus verifyJwt with Date.now mocked forward
Token signed to expire now, read 10s later → 401, not 200 — asserted both as verifyJwt throwing TokenExpiredError and as a real GET /api/v1/webhooks returning 401
No regression for a valid 5s nbf skew — nbf: now + 5 still passes after the clock moves
Revocation list checked on every request → 401 TOKEN_REVOKED — HTTP-level, plus logout and logout-all end to end (including that logout-all kills a different token of the same wallet and leaves other wallets alone)
Redis store — new methods implemented and their error-fallback paths tested

🚀 Deployment Notes

Mainnet Readiness

This code is ready for production deployment
All critical tests pass — see the known-issues note below
Security review approved
No temporary debug code
No TODO comments

Breaking Changes

Clients with a clock more than 5s ahead of the API must re-authenticate. Documented in the OpenAPI bearerAuth description.
POST /auth/logout / logout-all responses gain revokedAccessToken / refreshSessionRevoked / revokedAccessTokens fields. Additive only.

Known issues inherited from `main` (out of scope, flagged for maintainers)

These fail identically on main and are unrelated to this issue:

npm test coverage gate. jest.config.js requires 80% global coverage. On main the backend is at 37.11% with 33 failing suites; on this branch it is 67.85% with 0 failing suites. The remaining gap is large parts of src/ having no tests at all (operationalMetrics.ts, eventPollingService.ts, impersonationSessionService.ts, writeAheadAuditLog.ts, src/tests/*, …). Closing it is a repo-wide programme.
npm run prisma:schema-check. ScopedAdminToken has both keyId @unique and @@index([keyId]); the committed migration created the uniqueness as an implicit sqlite_autoindex, so prisma migrate diff wants to redefine it. Making it zero-diff needs a DROP INDEX, which scripts/check-migrations.js treats as an error — the two gates cannot both be satisfied without a maintainer decision.
dependency-security.yml's pnpm audit and CodeQL also fail on main and depend on repository settings/network, not on this diff.

✅ Reviewer Checklist

📞 Questions or Issues?

🤔 Confused about security checklist? → See docs/SECURITY_CHECKLIST.md
🔍 Marking finding as false positive? → Follow docs/FALSE_POSITIVE_HANDLING.md
🆘 Need security review help? → Tag @security-team in comments

main is currently unbuildable and its test suite is red, so every back-end CI job fails before it reaches the code under review. The breakage all traces back to two bad merges (9a15975, 7300a48) that truncated a Prisma model block, dropped a closing brace, renamed an imported limiter and replaced the idempotency replay cache. Prisma schema - close `WalletTenantAssociation` and separate it from `IdempotencyKey` (a missing `}` made `prisma generate` fail, so `@prisma/client` stayed an uninitialised stub and every suite crashed on import) - add `SessionAuditLog`, `Transaction.deletedAt` and `WebhookEndpoint.tenantId`, all of which sessionAudit.ts and the tenant boundary guard already query - add the matching migration and refresh the committed SQLite dev.db Type errors - import `readsLimiter` in vaultEndpoints.ts (used by GET /receipts) - restore the idempotency replay cache as idempotencyStore.ts and re-export it from idempotency.ts, so transferOrchestrator.ts, vaultEndpoints.ts, index.ts and idempotencyRetention.ts resolve - fix the unterminated `if` in diffSchemaShapes and a possibly-undefined `baseline.properties` read in apiContractSnapshots.ts - build the OTel resource through whichever factory the installed @opentelemetry/resources major exposes (v1 `new Resource()`, v2 `resourceFromAttributes()`) - `ZodObject._shape` → `.shape` for Zod 4 - return the strategy-switch 200 response, order receipts by `timestamp`, serialise session metadata, and type the request mocks in src/tests Error contract - restore `summary`, `errors` and 404 `path` on the error envelope Tests - issues711 "newly added required fields" mutated the live schema instead of the baseline snapshot, so it asserted against a scenario that can never produce the expected diff

An unauthenticated caller could pass `?limit=100000` and have it forwarded straight into Prisma's `take`, forcing the API to materialise 100k vault rows and OOM-kill the 512MB container. Chosen behaviour (documented in the route, the spec and the tests): reject rather than silently clamp. A caller asking for 100000 rows has a bug or is probing, and quietly returning 50 hides that behind a response that looks like a complete page. So `limit > 50` fails fast with `400` and `code: 'LIMIT_EXCEEDED'`, and the body repeats the ceiling. `page` is the opposite case — a benign mistake — so it is clamped into 1..1000 and the effective value is echoed in the pagination envelope. - new `middleware/paginationGuard.ts`: `DEFAULT_PAGE_SIZE` (20), `MAX_PAGE_SIZE` (50), `MAX_PAGE` (1000), `resolvePagination()` and the `enforcePaginationLimits()` middleware - new `routes/vaults.ts`: `GET /api/v1/vaults`, rate limited, reads `limit + 1` rows for the lookahead, and never exposes `tenantId` - `parsePaginationQuery` gains `maxPage` and clamps out-of-range pages; `PaginationQuerySchema.page` accepts a signed integer so those requests reach the clamp instead of being rejected - OpenAPI: reusable `pageSize`/`pageNumber` parameters carrying the ceilings, plus a `GET /api/v1/vaults` path documenting the LIMIT_EXCEEDED response; `openapi.json` regenerated - `GET /api/v1/vaults` joins the committed contract snapshots, so the response shape is now covered by the backward-compatibility check - tests spy on the Prisma client to prove no read is ever issued with a `take` above the ceiling, that an oversized limit is rejected before any query runs, and that the committed `openapi.json` still matches

…request The verifier applied one shared tolerance to every time claim, so a token stayed acceptable for 60s past `exp`. A stolen bearer token therefore kept authorising `POST /vault/:id/withdraw` for a full minute after the user logged out, and nothing consulted a revocation list at all on the request path — `/auth/logout` only returned 200 without revoking anything. Time claims (backend/src/auth.ts) - add `assertTimeClaims()`, `TokenExpiredError` and `TokenNotYetValidError`, and an optional `nbf` claim on JwtPayload - `exp` is checked with **zero** tolerance and is inclusive of the expiry second (RFC 7519: a token is invalid at and after `exp`) - only `nbf`/`iat` get `CLOCK_SKEW_TOLERANCE_SECONDS` (5s) of slack, for clock skew between the pod and whatever minted the token Revocation (backend/src/tokenRevocation.ts) - `RevocationStore` gains `revokeWalletBefore()` and `isWalletRevokedBefore()`: a per-wallet high-water mark rather than an id list, so `logout-all` stays O(1) per wallet. The marker never moves backwards, so a later, broader revocation always wins - `revokeAllForWallet()` no longer just deletes records — it recorded nothing, which silently un-revoked every token it touched - Redis store implements the new methods and falls back to its in-process store on error, including for `revokeAllForWallet` (was `return 0`) - the store is now actually wired to Redis when `REDIS_URL` is set, so a logout handled by one pod is visible to the others Request path - `requireAuth` checks the revocation list on every authenticated request and answers 401 `TOKEN_REVOKED`; it fails **closed** with 503 if the store itself is unreachable rather than downgrading to "token is fine" - `/auth/logout` revokes the presented `jti` and, when a refreshToken is supplied, the whole refresh family - `/auth/logout-all` writes the wallet marker and revokes every refresh family for the wallet - OpenAPI: the `bearerAuth` scheme documents the zero-tolerance `exp`, the 5s `nbf` skew and the per-request revocation check Tests: 29 new cases in `jwtExpiryAndRevocation.test.ts`, including a token signed to expire *now* and read 10s later with a mocked `Date.now` (401, not 200), the 59s case the old 60s tolerance allowed, a 5s `nbf` skew that must still pass, logout/logout-all over HTTP, and the Redis-error fallback path.

drips-wave · 2026-09-30T03:44:42Z

@ToryMic Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

ToryMic · 2026-09-30T03:50:21Z

🧭 CI triage — which red checks are mine and which are not

main is currently red across the board (verified against the main push run 36430911829 and the run list for main at 711c4332). Every check below fails identically on main; none is caused by this diff. Measured locally against a clean main worktree:

Check	`main`	This branch	Blocked by
Backend test suites	33 failed suites / 49 failed tests	0 failed / 93 suites, 1371 tests	— fixed here
Backend global coverage	37.11%	67.85%	`jest.config.js` requires 80%
`Backend build` (tsc)	fails (`tsc` error TS1005)	✅ pass	— fixed here
`Backend lint + test`	❌	❌	`npm audit --audit-level=high` (pre-existing: 5 high, needs breaking majors)
`Backend Governance`	❌	❌	`prisma:schema-check` (pre-existing `ScopedAdminToken` index)
`Backend Test Coverage (>= 80%)`	❌	❌	coverage threshold
`Frontend Test Coverage (>= 70%)`	❌	❌	frontend untouched by this PR
`CodeQL (TypeScript)`	❌	❌	`frontend/package-lock.json` out of sync with `package.json`
`CodeQL (Rust)` / `Cargo Security Audit`	❌	❌	`cargo build` failure in `contracts/` (untouched)
`Governance & PR Standards` / `Dependency Security Scan` / `Dependency Vulnerability Audit`	❌	❌	repo has no `pnpm-lock.yaml`, so `pnpm install --frozen-lockfile` can never succeed
`NPM Audit (Frontend & Backend)`	❌	❌	same dependency advisories
`Backend build`, `Shared API schemas typecheck + test`, `gitleaks`, `Slither`, `pnpm version check`, `Security Review Summary`	✅	✅	—

Green on this branch and worth calling out

Backend build — main does not type-check at all; a missing } in prisma/schema.prisma made prisma generate fail, leaving @prisma/client an uninitialised stub.
The backend test suite goes from 49 failures to 0, and global coverage from 37% to 68%.
Verify OpenAPI documentation (git status --porcelain openapi.json after regeneration) passes again — the committed spec and swagger.ts had drifted.
ci:governance's check-migrations.js, check:migrations:canary, snapshots:check and check-adrs.js all pass.

If a maintainer wants a follow-up PR (deliberately kept out of this one, each is a separate concern):

Raise real test coverage for the untested half of src/ — the only way past the 80% gate.
Reconcile ScopedAdminToken's keyId @unique + @@index([keyId]) with its migration. prisma migrate diff wants a DROP INDEX, which scripts/check-migrations.js classifies as an error, so the two gates currently contradict each other.
Commit a pnpm-lock.yaml, or drop --frozen-lockfile from the four workflows that use it.
Sync frontend/package-lock.json and bump the advisories flagged by npm audit (both need breaking majors).

…comment Two review-level corrections to the revocation path added in the previous commit: - `isAccessTokenRevoked` looked the wallet marker up under the raw `sub` claim. Revocations are written under the canonical (upper-case) address via `normalizeWalletAddress`, so a token whose `sub` happened to be lower-case would not have matched a wallet-wide revocation. Normalise the lookup key the same way the write path does. - requireAuth's comment claimed a `res.headersSent` guard that was never implemented. Replace it with the reasoning that actually matters: Express ignores middleware return values, so returning before `next()` is safe for route usage, and the single direct caller passes a synchronous next().

…s path `transferOrchestrator.test.ts` exercises the happy path end to end, but with no `REDIS_URL` the `redisClientManager` never reports ready, so `IdempotencyStore.redis` returns null and every Redis helper is skipped — the store's Redis branch, and more importantly its error fallback, had no coverage at all. These tests drive the store through a stub client so they reach: the Redis get/set/del round trip, conflict detection across instances, the read/write/delete failure fallbacks, and `pruneStaleKeys` across expired TTL, unparsable payloads and dryRun. Plus the in-process semantics that money-moving code relies on: single execution, replay, fingerprint conflict, in-flight coalescing, and that a rejected operation frees the pending slot for a retry. idempotencyStore.ts: 70.9% -> 94.5% statements, 50.9% -> 81.8% branches.

…d-allows-limit-100000-to-oom-the-api' into fix/1431-auth-middleware-accepts-expired-jwt-for-60s-due-to-clocktolerance-misconfiguration

ToryMic · 2026-09-30T04:08:31Z

✅ Final local verification on this branch

cd backend
npx prisma generate
npm run build                                   # tsc → 0 errors
npm run lint                                    # 0 errors (422 pre-existing warnings)
npx jest --runInBand
#   Test Suites: 94 passed, 94 total
#   Tests:       1397 passed, 1397 total        (0 failures)

npm run generate:openapi && git diff --exit-code openapi.json   # in sync
npm run snapshots:check                                         # ✅
node scripts/check-migrations.js                                # ✅ (warnings only)
npm run check:migrations:canary                                 # ✅ (warnings only)
node scripts/check-adrs.js                                      # ✅
npm run prisma:generate                                         # ✅

Coverage moved with it: main 37.11% → this branch 68.21% global statements. The 80% gate is still red because a large part of src/ has no tests at all — see the triage table above. backend/src/idempotencyStore.ts went 70.9% → 94.5% statements once its Redis path was covered.

Branch status: upstream/main is an ancestor of both branches (git rev-list --count HEAD..upstream/main → 0), so both PRs are MERGEABLE with zero conflicts. #1516 is stacked on #1515 and carries its commits; after #1515 merges, #1516's diff collapses to its own three commits.

ToryMic added 3 commits September 29, 2026 23:10

ToryMic added 3 commits September 29, 2026 23:53

Merge branch 'fix/1430-get-vaults-query-does-not-enforce-max-limit-an…

03a87e1

…d-allows-limit-100000-to-oom-the-api' into fix/1431-auth-middleware-accepts-expired-jwt-for-60s-due-to-clocktolerance-misconfiguration

ToryMic mentioned this pull request Sep 30, 2026

[1430] GET /vaults query does not enforce max limit and allows limit=100000 to OOM the API #1515

Open

40 of 52 tasks

ToryMic mentioned this pull request Sep 30, 2026

[1433] Prisma $transaction isolation level defaults to ReadCommitted allowing phantom reads in allocation rebalance #1517

Open

41 of 54 tasks

Navigation Menu

[1431] Auth middleware accepts expired JWT for 60s due to clockTolerance misconfiguration - #1516

[1431] Auth middleware accepts expired JWT for 60s due to clockTolerance misconfiguration#1516
ToryMic wants to merge 6 commits into
Junirezz:mainfrom
ToryMic:fix/1431-auth-middleware-accepts-expired-jwt-for-60s-due-to-clocktolerance-misconfiguration

ToryMic commented Sep 30, 2026

Uh oh!

drips-wave Bot commented Sep 30, 2026

Uh oh!

ToryMic commented Sep 30, 2026

Uh oh!

ToryMic commented Sep 30, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ToryMic commented Sep 30, 2026

📋 Description

Goal

Changes

🔗 Type of Change

🛡️ Risk Assessment

Risk Level

Blast Radius & Impact Analysis

🔄 Rollback Plan

Rollback Strategy & Feasibility

Rollback Trigger Criteria

Step-by-Step Rollback Procedure

⚡ Performance Impact

Performance & Resource Assessment

🔒 SECURITY REVIEW

Option A: Fixed in This PR ✅

📝 Testing

Functional Testing

Security Testing

Test Coverage

🚀 Deployment Notes

Mainnet Readiness

Breaking Changes

Known issues inherited from main (out of scope, flagged for maintainers)

✅ Reviewer Checklist

📞 Questions or Issues?

Uh oh!

drips-wave Bot commented Sep 30, 2026

Uh oh!

ToryMic commented Sep 30, 2026

🧭 CI triage — which red checks are mine and which are not

Uh oh!

ToryMic commented Sep 30, 2026

✅ Final local verification on this branch

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Known issues inherited from `main` (out of scope, flagged for maintainers)