feat: securely handle incoming password payloads for development#1600
feat: securely handle incoming password payloads for development#1600
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds an optional Changes
Sequence DiagramsequenceDiagram
participant Client
participant AuthzController
participant CommonService
participant AuthzService
Client->>AuthzController: addUserDetails(userInfo) / login(loginUserDto)
Note over AuthzController: if password exists && !isPasswordEncrypted
AuthzController->>CommonService: dataEncryption(password)
CommonService-->>AuthzController: encryptedPassword
Note over AuthzController: replace password with encryptedPassword
AuthzController->>AuthzService: addUserDetails(userInfo) / login(clientInfo, email, password)
AuthzService-->>AuthzController: serviceResponse
AuthzController-->>Client: serviceResponse
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/api-gateway/src/authz/authz.service.ts`:
- Around line 54-62: The login method in authz.service.ts is publishing raw
plaintext passwords in the NATS payload via natsClient.sendNatsMessage to the
'user-holder-login' subject; instead, before calling sendNatsMessage in
AuthzService.login, stop forwarding the plain password when isPasswordEncrypted
is false and re-wrap it at the gateway (for example: encrypt/nonce-wrap or
exchange the plaintext for a short-lived gateway-issued token or hashed value)
and include that wrapped value in the payload instead of the raw password;
update the payload construction around payload = { email, password, ... } and
the call to this.natsClient.sendNatsMessage(this.authServiceProxy,
'user-holder-login', payload) so downstream consumers never see the plaintext
while preserving isPasswordEncrypted/isPasskey flags.
In `@apps/api-gateway/src/user/dto/add-user.dto.ts`:
- Around line 43-47: Remove the exposed plaintext-password flag from the DTO:
delete the isPasswordEncrypted property (remove `@ApiPropertyOptional`,
`@Transform`, `@IsOptional`, `@IsBoolean` and the isPasswordEncrypted?: boolean
declaration) so the API no longer accepts or documents this field; instead,
ensure the gateway/signup code that previously relied on isPasswordEncrypted
always treats incoming passwords as encrypted (or performs server-side
normalization/encryption before calling the internal add-user flow) so no
plaintext password mode is propagated to downstream code (search for usages of
isPasswordEncrypted in signup handlers and the add-user flow and remove/replace
them with a server-side normalization step).
In `@apps/user/src/user.service.ts`:
- Around line 335-337: The current conditional that sets decryptedPassword uses
a truthy check on userInfo.isPasswordEncrypted which treats an omitted field as
false and changes legacy behavior; update the logic in the signup flow where
decryptedPassword is computed to use a nullish-coalescing default (e.g.,
userInfo.isPasswordEncrypted ?? true) so an undefined value still triggers
this.commonService.decryptPassword(userInfo.password) when appropriate; locate
the assignment computing decryptedPassword in user.service (the line using
this.commonService.decryptPassword) and replace the truthiness check with the
nullish-coalescing check to match the behavior used in login().
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5f234678-59e5-49b1-88a6-fa5a9171f5b2
📒 Files selected for processing (7)
apps/api-gateway/src/authz/authz.controller.tsapps/api-gateway/src/authz/authz.service.tsapps/api-gateway/src/user/dto/add-user.dto.tsapps/api-gateway/src/user/dto/login-user.dto.tsapps/user/dtos/login-user.dto.tsapps/user/interfaces/user.interface.tsapps/user/src/user.service.ts
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/user/src/user.service.ts`:
- Around line 335-338: Normalize userInfo.password before splitting into passkey
vs non-passkey flow: compute a single plainPassword (e.g., use the existing
isPasswordEncrypted check and call this.commonService.decryptPassword only if
needed) and then use that plainPassword in both the passkey branch and the
non-passkey branch instead of calling decrypt inside only one branch; update
references to decryptedPassword/userInfo.password in the passkey handling code
so it stores/uses the normalized plainPassword and avoid decrypting plaintext
when isPasswordEncrypted is false.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ca935849-be9b-44aa-b6f1-a8b3899e1286
📒 Files selected for processing (1)
apps/user/src/user.service.ts
Signed-off-by: Krishna Waske <krishna.waske@ayanworks.com>
186a36c to
7629086
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
apps/api-gateway/src/user/dto/add-user.dto.ts (1)
43-47:⚠️ Potential issue | 🔴 Critical
isPasswordEncryptedstill exposes caller-controlled plaintext mode on signup.Line 47 keeps this flag in the public DTO, which preserves a plaintext-password API mode at the edge. This broadens secret-handling surface and should be removed from the external contract; normalization/encryption should be enforced server-side before forwarding.
Proposed DTO-side change
- `@ApiPropertyOptional`({ example: true, default: true, description: 'Indicates if the password is encrypted' }) - `@IsOptional`() - `@Transform`(({ value }) => (value !== undefined && null !== value ? value : true)) - `@IsBoolean`({ message: 'isPasswordEncrypted should be boolean' }) - isPasswordEncrypted?: boolean;#!/bin/bash # Verify all remaining usages before removing the field end-to-end. # Expected: usages should be limited and then eliminated from public DTO/controller contracts. rg -n -C2 --type=ts '\bisPasswordEncrypted\b'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/api-gateway/src/user/dto/add-user.dto.ts` around lines 43 - 47, Remove the public isPasswordEncrypted property from the AddUserDto (delete the isPasswordEncrypted field, its `@ApiPropertyOptional/`@IsOptional/@Transform/@IsBoolean decorators) so callers cannot request plaintext mode; find and update all codepaths still referencing isPasswordEncrypted (search for symbol isPasswordEncrypted) and ensure password normalization/encryption is performed unconditionally in your server-side user service/handler (e.g., in the signup/createUser flow) before forwarding/storing credentials, and update any tests and API docs that referenced the flag.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/api-gateway/src/user/dto/add-user.dto.ts`:
- Around line 33-36: The Swagger example for the DTO property isPasskey is a
string ('false') but the validator `@IsBoolean` expects a boolean; update the
`@ApiProperty` decorator on isPasskey in add-user.dto (the isPasskey field) to use
a boolean example (e.g. example: false) so the OpenAPI spec and runtime
validation match.
---
Duplicate comments:
In `@apps/api-gateway/src/user/dto/add-user.dto.ts`:
- Around line 43-47: Remove the public isPasswordEncrypted property from the
AddUserDto (delete the isPasswordEncrypted field, its
`@ApiPropertyOptional/`@IsOptional/@Transform/@IsBoolean decorators) so callers
cannot request plaintext mode; find and update all codepaths still referencing
isPasswordEncrypted (search for symbol isPasswordEncrypted) and ensure password
normalization/encryption is performed unconditionally in your server-side user
service/handler (e.g., in the signup/createUser flow) before forwarding/storing
credentials, and update any tests and API docs that referenced the flag.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 401614ef-0000-4fae-a8c3-68bc0561e97c
📒 Files selected for processing (3)
apps/api-gateway/src/authz/authz.controller.tsapps/api-gateway/src/user/dto/add-user.dto.tsapps/api-gateway/src/user/dto/login-user.dto.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/api-gateway/src/authz/authz.controller.ts
- apps/api-gateway/src/user/dto/login-user.dto.ts
Signed-off-by: Krishna Waske <krishna.waske@ayanworks.com>
Signed-off-by: Krishna Waske <krishna.waske@ayanworks.com>
|



What
Summary by CodeRabbit