-
Notifications
You must be signed in to change notification settings - Fork 0
[SSF-145] - Cognito integration account creation #113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
e63be34
eea6561
9cc525f
33e1acd
0977f43
0d2536f
77b06cb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,8 @@ | ||
| import { Injectable } from '@nestjs/common'; | ||
| import { | ||
| ConflictException, | ||
| Injectable, | ||
| InternalServerErrorException, | ||
| } from '@nestjs/common'; | ||
| import { | ||
| AdminDeleteUserCommand, | ||
| AdminInitiateAuthCommand, | ||
|
|
@@ -7,6 +11,7 @@ import { | |
| ConfirmSignUpCommand, | ||
| ForgotPasswordCommand, | ||
| SignUpCommand, | ||
| AdminCreateUserCommand, | ||
| } from '@aws-sdk/client-cognito-identity-provider'; | ||
|
|
||
| import CognitoAuthConfig from './aws-exports'; | ||
|
|
@@ -73,6 +78,37 @@ export class AuthService { | |
| return response.UserConfirmed; | ||
| } | ||
|
|
||
| async adminCreateUser({ | ||
| firstName, | ||
| lastName, | ||
| email, | ||
| }: Omit<SignUpDto, 'password' | 'phone'>): Promise<string> { | ||
| const createUserCommand = new AdminCreateUserCommand({ | ||
| UserPoolId: CognitoAuthConfig.userPoolId, | ||
| Username: email, | ||
| UserAttributes: [ | ||
| { Name: 'name', Value: `${firstName} ${lastName}` }, | ||
| { Name: 'email', Value: email }, | ||
| { Name: 'email_verified', Value: 'true' }, | ||
dburkhart07 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ], | ||
| DesiredDeliveryMediums: ['EMAIL'], | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should change the email from the default to 1) indicate that their application was approved and 2) provide further information other than simply the password, like how to access the signup page, or even a link to the application. When I got the email I wasn't quite sure what to do with it You can look at my cognito docs for instructions on how to change the default email, lmk if you have any questions
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how to access this page will definitely change, but we can just put the link as localhost for right now, and change it later, so i like the idea of more information on what to do with the password as well. the application approved sounds good too, but im not sure if there is a separate automated email for that. i know in many modern flows (for example, email verification after you submit a job application), you receive 2 emails: one saying your application was submitted, and another being to verify your email. if we have a separate one for this, i suggest we keep the template basic on how to setup the account.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm fine to table this discussion for now since the email template can be easily changed without code later. If the intended flow is to have two emails that's fine with me, although it seems easier to implement and simpler to just have 1 email from cognito rather than having a call to cognito and a call to ses. |
||
| }); | ||
|
|
||
| try { | ||
| const response = await this.providerClient.send(createUserCommand); | ||
| const sub = response.User?.Attributes?.find( | ||
| (attr) => attr.Name === 'sub', | ||
| )?.Value; | ||
| return sub; | ||
| } catch (error) { | ||
| if (error.name == 'UsernameExistsException') { | ||
| throw new ConflictException('A user with this email already exists'); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if there is an email conflict doesn't it make more sense to notify the user when they submit the application rather than the admin who is approving/denying the application? there isn't really anything the admin can do if they find that an email already exists in the db other than reach out directly
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hmm this is a good question, and likely related to product. for the pantry and food manufacturer flow: a DB user should be created with an empty cognito sub when the application is submitted. we could make an api call to check if the primary email exists in cognito and throw an error otherwise (since having a cognito account makes them an official user) and not allow for modal submission. for admin and volunteers: this is a little harder, since i am not quite sure what our frontend flow is going to be for creating these two yet. how is this email going to be obtained from the frontend?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think checking if the primary email already exists in cognito to allow for modal submission is a good solution for pantry and food manufacturer
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For admins and volunteers, the email will be provided directly (we do already have volunteer creation in the frontend on the admin volunteer management page). But for all four user types, a user should only have a cognito account if they also have a db user, so checking that the email does not already exist in our own db should be sufficient to know it won't exist in cognito (so the check you added here should hopefully never need to activate, but it should be fine to have it as a failsafe). I did have it written down in my list of future work to deal with the case where we try to create a user with an email that already exists, so I don't think you need to worry about updating the existing db user creation flows to account for that in this PR.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Makes sense to not worry about it in this pr. Just want to raise one potential case for us to think about if we decide to check against the db in the future. If an application gets rejected, and they re-apply, it won't let them submit their application again because they already have an account in the db even if they don't have a cognito account
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Based off the client meeting today, our flow of applying/rejecting may change. Based on this, I think it may be best to hold off on this logic for now. Definitely good to keep in mind right now though.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yep! with how they're planning on handling approving/denying the re-application scenario should not be an issue |
||
| } else { | ||
| throw new InternalServerErrorException('Failed to create user'); | ||
| } | ||
| } | ||
| } | ||
|
|
||
| async verifyUser(email: string, verificationCode: string): Promise<void> { | ||
| const confirmCommand = new ConfirmSignUpCommand({ | ||
| ClientId: CognitoAuthConfig.userPoolClientId, | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -15,8 +15,12 @@ import { | |
| AllergensConfidence, | ||
| } from './types'; | ||
| import { ApplicationStatus } from '../shared/types'; | ||
| import { UsersService } from '../users/users.service'; | ||
| import { User } from '../users/user.entity'; | ||
| import { Role } from '../users/types'; | ||
|
|
||
| const mockRepository = mock<Repository<Pantry>>(); | ||
| const mockUsersService = mock<UsersService>(); | ||
|
|
||
| describe('PantriesService', () => { | ||
| let service: PantriesService; | ||
|
|
@@ -79,6 +83,10 @@ describe('PantriesService', () => { | |
| provide: getRepositoryToken(Pantry), | ||
| useValue: mockRepository, | ||
| }, | ||
| { | ||
| provide: UsersService, | ||
| useValue: mockUsersService, | ||
| }, | ||
| ], | ||
| }).compile(); | ||
|
|
||
|
|
@@ -163,16 +171,33 @@ describe('PantriesService', () => { | |
| // Approve pantry by ID (status = approved) | ||
| describe('approve', () => { | ||
| it('should approve a pantry', async () => { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why was this removed? We now don't have a test for if the pantry approval process works. I think we should be asserting the following:
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fixed the test |
||
| mockRepository.findOne.mockResolvedValueOnce(mockPendingPantry); | ||
| const mockPantryUser: Partial<User> = { id: 1, email: 'test@test.com' }; | ||
| const mockCreatedUser: Partial<User> = { id: 2, role: Role.PANTRY }; | ||
|
|
||
| const mockPendingPantryWithUser: Partial<Pantry> = { | ||
| ...mockPendingPantry, | ||
| pantryUser: mockPantryUser as User, | ||
| }; | ||
|
|
||
| mockRepository.findOne.mockResolvedValueOnce( | ||
| mockPendingPantryWithUser as Pantry, | ||
| ); | ||
| mockUsersService.create.mockResolvedValueOnce(mockCreatedUser as User); | ||
| mockRepository.update.mockResolvedValueOnce(undefined); | ||
|
|
||
| await service.approve(1); | ||
|
|
||
| expect(mockRepository.findOne).toHaveBeenCalledWith({ | ||
| where: { pantryId: 1 }, | ||
| relations: ['pantryUser'], | ||
| }); | ||
| expect(mockUsersService.create).toHaveBeenCalledWith({ | ||
| ...mockPantryUser, | ||
| role: Role.PANTRY, | ||
| }); | ||
| expect(mockRepository.update).toHaveBeenCalledWith(1, { | ||
| status: 'approved', | ||
| status: ApplicationStatus.APPROVED, | ||
| pantryUser: mockCreatedUser, | ||
| }); | ||
| }); | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.