Skip to content

fix(rockets-auth): enforce the active flag on token validation; patch RepositoryQueryException context wipe#30

Open
kauandotnet wants to merge 2 commits into
btwld:mainfrom
kauandotnet:fix/jwt-adapter-active-gate
Open

fix(rockets-auth): enforce the active flag on token validation; patch RepositoryQueryException context wipe#30
kauandotnet wants to merge 2 commits into
btwld:mainfrom
kauandotnet:fix/jwt-adapter-active-gate

Conversation

@kauandotnet

Copy link
Copy Markdown

What

Two small fixes found while running rockets-auth in production-shaped integration tests:

  1. RocketsJwtAuthAdapter now rejects inactive users during access-token validation. Login already enforces active (LocalUserInactiveException), but the token path did not — a deactivated user's outstanding access tokens kept working until expiry. The adapter now checks user.active after the subject lookup and fails with 401, mirroring the login-path semantics.

  2. scripts/patch-concepta-runtime-context.cjs also patches @concepta/nestjs-repository. RepositoryQueryException has the same Object.assign({}, super.context) bug as the nestjs-common/nestjs-crud exceptions the script already fixes: the derived constructor wipes context.originalError, so consumers can never reach the underlying driver error (e.g. to map postgres 23505 unique violations to 409 Conflict).

Validation

Verified downstream (NestJS 12 ESM app, postgres, HTTP integration suite): deactivating a user 401s their live access token on the very next request and reactivation restores it; with the repository patch applied, unique violations surface through context.originalError and map to 409. Happy to add upstream e2e coverage for the active gate if wanted.

Login already enforces the active flag (LocalUserInactiveException), but
RocketsJwtAuthAdapter.validateToken did not — a deactivated user could keep
using outstanding access tokens until expiry. Check user.active after the
subject lookup and fail with 401, mirroring the login-path semantics.
@concepta/nestjs-repository RepositoryQueryException has the same
Object.assign({}, super.context) bug as the nestjs-common/nestjs-crud
exceptions this script already patches: the derived constructor wipes
context.originalError, so consumers cannot map the underlying driver
error (e.g. postgres 23505 unique violations to 409 Conflict).
@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric Results
Complexity 0
Duplication 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant