[SSF-145] - Cognito integration account creation by dburkhart07 · Pull Request #113 · Code-4-Community/ssf

dburkhart07 · 2026-02-21T03:22:21Z

ℹ️ Issue

Closes #145

📝 Description

This PR goes into the process of creating a new user through Cognito. Our existing Auth Service that utilized the Cognito API required a password, so we needed to use a new one that generates a temporary password, and emails it to the new user that we want to create.

When the user enters their temporary password for the first time, amplify stores a challenge that tells us that we need to create a new permanent password. Because of this, we needed to add in a new frontend modal into what we already had. From there, we can get the user cognito client sub, which is what we now store in our database.

The pantry and food manufacturer flow is slightly different, as they have linked users which are already created as they wait for approval after filling out the application. Because of that, we implement a check to see what their role is to determine if we update it in the database, or create a new user.

✔️ Verification

Run the following steps:

Tested users receive emails only when their email does not exist
Was able to successfully reset my password through the frontend UI
Verified pantries and food manufacturers that do not have an account receive an email, but no additional user is created (just sets the cognito client sub)

🏕️ (Optional) Future Work / Notes

Pending testing being written for this.

maxn990

Great first pass!

In addition to the comments I left, I found one more bug I wanted to mention. After I create an account as a pantry, the first time I try to access the dashboard after creating my account I get the following problem:

It's fine after I refresh though

apps/backend/src/auth/auth.service.ts

maxn990 · 2026-02-22T21:58:49Z

apps/backend/src/pantries/pantries.service.ts

+    const createUserDto: userSchemaDto = {
+      email: pantry.pantryUser.email,
+      firstName: pantry.pantryUser.firstName,
+      lastName: pantry.pantryUser.lastName,
+      phone: pantry.pantryUser.phone,
+      role: Role.PANTRY,
+    };


this dto is being created multiple times, think we can remove some repeat code

not quite sure i understand this. are you referencing that we create this dto in the pantries and fm service, and because of that we should abstract it? if thats the case, im not quite sure if that abstraction is really going to save much repeat code. perhaps i am missing something though.

I'm referring more to the fact that pantry.pantryUser already has all the same fields as the DTO, so we're just manually remapping properties that are already there. Instead of constructing the DTO field by field, you could do { ...pantry.pantryUser, role: Role.PANTRY } and pass that directly. Same applies in the manufacturers service.

apps/backend/src/users/users.controller.ts

apps/frontend/src/containers/loginPage.tsx

apps/backend/src/users/users.service.ts

maxn990 · 2026-02-23T01:18:03Z

apps/backend/src/users/users.service.ts

+      firstName,
+      lastName,
+      email,
+      phone,


if phone is here maybe it should be included in the dto? but then we should send it to cognito.

i guess the question is what's the purpose of including the phone number:

cognito uses it for mfa or invitation messages

db stores it for some other reason

i personally am fine with removing it. if we plan on adding an option for mfa verification down the line, maybe its good to include this. if not (or we just want to use email verification), then i think we are fine to just remove it in this case. @sam-schu @Yurika-Kan, thoughts?

Are we asking whether we should be storing the phone in cognito, or whether we should be storing it in our database at all?

Are we storing it in cognito?

maxn990 · 2026-02-23T01:57:35Z

apps/backend/src/auth/auth.service.ts

+      return sub;
+    } catch (error) {
+      if (error.name == 'UsernameExistsException') {
+        throw new ConflictException('A user with this email already exists');


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

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?

@sam-schu @Yurika-Kan

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

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.

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

maxn990 · 2026-02-23T02:02:01Z

apps/backend/src/auth/auth.service.ts

+        { Name: 'email', Value: email },
+        { Name: 'email_verified', Value: 'true' },
+      ],
+      DesiredDeliveryMediums: ['EMAIL'],


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

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.

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.

apps/frontend/src/containers/loginPage.tsx

dburkhart07 added 4 commits February 20, 2026 22:10

Final commit

e63be34

Final commit

eea6561

Final commit fr this time

9cc525f

Merged main

33e1acd

Juwang110 self-requested a review February 23, 2026 00:51

maxn990 requested changes Feb 23, 2026

View reviewed changes

Implemented fixes

0977f43

Comments

Conversation

dburkhart07 commented Feb 21, 2026

ℹ️ Issue

📝 Description

✔️ Verification

🏕️ (Optional) Future Work / Notes

Uh oh!

maxn990 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

maxn990 left a comment •

edited

Loading