feat: update send email verification API default parameter for sending email #1481
Conversation
Signed-off-by: shitrerohit <[email protected]>
…ault Signed-off-by: sujitaw <[email protected]>
WalkthroughAdds an optional isDefaultVerified flag across DTOs and interfaces, updates user creation flow to optionally skip sending verification emails and auto-verify when flagged, introduces a new admin-only manual verification endpoint, and adds a success response message. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API as API Gateway
participant Authz as AuthzController
participant UserSvc as User Service
participant Email as Email Service
Client->>API: POST /create-user {email,..., isDefaultVerified?}
API->>UserSvc: createUser(payload)
alt isDefaultVerified == true
UserSvc->>UserSvc: create user record
UserSvc->>UserSvc: verifyEmail(user)
UserSvc-->>Client: 201 Created (user, verified)
else isDefaultVerified == false
UserSvc->>Email: sendVerificationEmail(user)
Email-->>UserSvc: queued/sent
UserSvc-->>Client: 201 Created (user, pending verification)
end
Note right of Authz: Admin manual flow
Client->>Authz: POST /verify-mail-manually (PLATFORM_ADMIN)
Authz->>Authz: set clientAlias/default, set isDefaultVerified=true
Authz->>UserSvc: sendVerificationMail(payload)
UserSvc->>UserSvc: verifyEmail(user) / enqueue as appropriate
UserSvc-->>Client: 201 Created / success message
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 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 |
sujitaw
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/user/src/user.service.ts (1)
137-137: Initialize the variable for clarity.The variable
sendVerificationMailis declared but not initialized. While the logic works due to short-circuit evaluation on line 169, explicit initialization improves readability and makes the intent clearer.Apply this diff to initialize the variable:
- let sendVerificationMail: boolean; + let sendVerificationMail: boolean = false;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/api-gateway/src/user/dto/create-user.dto.ts(2 hunks)apps/user/src/user.service.ts(2 hunks)libs/common/src/interfaces/user.interface.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
apps/user/src/user.service.ts (2)
apps/api-gateway/src/authz/authz.service.ts (1)
sendVerificationMail(44-47)apps/user/src/user.controller.ts (1)
sendVerificationMail(58-60)
🔇 Additional comments (6)
libs/common/src/interfaces/user.interface.ts (1)
23-23: LGTM! Interface extension is backward compatible.The optional
isDefaultVerifiedfield is properly typed and maintains backward compatibility with existing code.apps/api-gateway/src/user/dto/create-user.dto.ts (2)
1-2: LGTM! Import additions are appropriate.The new imports
ApiHidePropertyandIsBooleanare necessary for theisDefaultVerifiedfield implementation.
42-45: LGTM! Field is properly decorated and validated.The
isDefaultVerifiedfield is correctly configured with:
@ApiHideProperty()to hide it from Swagger documentation@IsOptional()to make it optional@IsBoolean()for type validation- Sensible default value of
falseapps/user/src/user.service.ts (3)
116-116: LGTM! Properly extracts the new field.The destructuring includes the new
isDefaultVerifiedfield from theuserEmailVerificationparameter.
153-164: Conditional email sending logic is correct.The email verification is correctly skipped when
isDefaultVerifiedis true, allowing for immediate verification in the subsequent flow.
169-169: No issues: sendEmailForVerification only returns true or throws, sosendVerificationMail || isDefaultVerifiedcovers all edge cases.
|
As discussed in the CREDEBL call dated 15th October. The fix provided here is not the best way to enable registering users without email verification. As having the flag responsible for making the user verified by default can open path to attacks like spamming of users on CREDEBL. @sujitaw mentioned he would be revisiting the requirements with @shitrerohit Some discussed suggestions to implement user registration without email verification were as follows:
We should be flexible with updating the verification email logic as it is our own, not dependent on Keycloak |
ajile-in
changed the title
|
We can think of:
|
I believe the SMTP server would be a complete new feature regarding how someone sends email. For this specific issue I believe we can overlook that(even though a configurable email provider is what we want) for now. Let me know what you think. As this specific issue is mostly to avoid spamming of user accounts without verifying their email(no email required) with the suggested changes
Yes this was one of the options we discussed, however, as we don't have an admin portal, we can start with an API to add these users for the admin (CREDEBL) Also, I believe we'll also need to understand the use case for having this and if the base requirement is to add a large number of pre-approved users. This should help us get to the limit/number and if we want that in the first place.
Yess right |
Signed-off-by: sujitaw <[email protected]>
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/api-gateway/src/authz/authz.controller.ts(2 hunks)apps/api-gateway/src/authz/authz.service.ts(1 hunks)libs/common/src/response-messages/index.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
apps/api-gateway/src/authz/authz.controller.ts (4)
apps/api-gateway/src/authz/decorators/roles.decorator.ts (1)
Roles(6-6)apps/api-gateway/src/user/dto/create-user.dto.ts (1)
UserEmailVerificationDto(7-46)apps/api-gateway/src/user/utils/index.ts (1)
getDefaultClient(4-9)libs/common/src/interfaces/response.interface.ts (1)
IResponseType(1-7)
🔇 Additional comments (1)
libs/common/src/response-messages/index.ts (1)
18-18: Message addition looks good.The new success string slots in cleanly with the existing response message structure.
| userEmailVerification.isDefaultVerified = true; | ||
| const payload = { userEmailVerification }; | ||
| return this.natsClient.sendNatsMessage(this.authServiceProxy, 'send-verification-mail', payload); |
There was a problem hiding this comment.
Don’t auto-set isDefaultVerified for every send path.
sendVerificationMail now flips the flag to true for every caller, which makes the downstream user service treat every user as already verified and skip the email entirely—exactly the abuse scenario we’re trying to avoid. Please keep the default false (from the DTO) and only set it to true in the specific flows that really need auto-verification (e.g., a manual approval path) rather than here.
Apply this diff so the caller decides the flag:
- userEmailVerification.isDefaultVerified = true;
+ if (userEmailVerification.isDefaultVerified === undefined) {
+ userEmailVerification.isDefaultVerified = false;
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| userEmailVerification.isDefaultVerified = true; | |
| const payload = { userEmailVerification }; | |
| return this.natsClient.sendNatsMessage(this.authServiceProxy, 'send-verification-mail', payload); | |
| if (userEmailVerification.isDefaultVerified === undefined) { | |
| userEmailVerification.isDefaultVerified = false; | |
| } | |
| const payload = { userEmailVerification }; | |
| return this.natsClient.sendNatsMessage(this.authServiceProxy, 'send-verification-mail', payload); |
🤖 Prompt for AI Agents
In apps/api-gateway/src/authz/authz.service.ts around lines 45 to 47, the code
currently forces userEmailVerification.isDefaultVerified = true before sending
the message which causes downstream services to skip real verification; remove
that assignment so the DTO's default (false) is preserved and send the payload
as-is, and update any specific flows that legitimately require auto-verification
to set isDefaultVerified = true before calling this method instead of here.
What
Summary by CodeRabbit