auth app version #0.0.1 #205

NickDevX · 2025-12-01T19:44:49Z

First version auth app, Using library:
express.js for endpoint,
sequelize ORM,
nodemon - for fast server reload,
valibot - for middleware data validation,

mateacademy-ai-mentor

Review Summary

This is a strong submission with a well-organized structure and solid implementation of most features. However, a few critical issues related to the task requirements need to be addressed before this can be approved.

Login Redirect: The application must redirect to the profile page after a successful login, but it currently returns a JSON response. This is because the userService handles the HTTP response directly. Please refactor the login function to return data and let the authController be responsible for sending the redirect.
Unprotected Logout Route: The /logout route in src/routes/auth.route.js is missing the authMiddleware. This contradicts the requirement that logout should only be accessible to authenticated users.
Incorrect Error Handling: In src/services/user.service.js, the ApiError.badRequest method is called with an object instead of a string, leading to unhelpful error messages. Please ensure you pass a proper message string.

Once these key functional requirements are met, your project will be in great shape.

✨ Please rate this review in the Platform's notification center¹. I will be grateful for your feedback! ✨

Important

Fix the issues, commit the changes, and then re-request my review using the Re-request review button² in the Reviewers tab.

Tip

If you have any comments about this review, please leave a message in the Add a comment section below and mention me with the @mateacademy-ai-mentor tag³.
I will read your message during my next review of your pull request. Please do not reply directly to my comments, as that feature is not supported yet.

Caution

Do not close the pull request until the review is complete. Closing it early can lead to unexpected behavior and disrupt the review process.

src/controllers/profile.controller.js

mateacademy-ai-mentor · 2025-12-01T19:47:56Z

src/controllers/auth.controller.js

+const login = async (req, res) => {
+  const { email, password } = req.body;
+
+  await userService.login(res, { email, password });


According to the requirements, the user should be redirected to the profile page after a successful login. This function currently relies on the userService to send a response, which doesn't perform the redirect. Consider refactoring userService.login to return the necessary data (like tokens) instead of handling the res object directly. This would allow this controller to handle the response and perform the required redirect.

src/middlewares/authMiddleware.js

src/services/email.service.js

src/routes/auth.route.js

mateacademy-ai-mentor · 2025-12-01T19:47:57Z

src/services/user.service.js

+  await emailService.sendActivationMail(email, activationToken);
+}
+
+async function login(res, { email, password }) {


This function, along with refresh and generateTokens, accepts the res object to send a response. This is considered an anti-pattern as it mixes business logic (service layer) with presentation logic (controller layer). It also directly conflicts with the requirement to redirect to the profile page after login, as this implementation sends a JSON response instead. The controller should be responsible for all response handling.

src/services/user.service.js

… bugfix Apierror call

mateacademy-ai-mentor

Review Summary

Excellent work on this project! I am approving your submission as you've successfully implemented all the core requirements. Your error handling, validation, and routing are all very well done.

I have one important architectural suggestion for you to consider in future projects. While your current code works correctly, a more standard practice for protected routes is to have the authMiddleware verify the accessToken, decode the user's payload (e.g., { id, email }), and attach it to the request object, like req.user = userPayload;. Your controllers can then simply use req.user.id instead of relying on the refreshToken for user identification. This makes your API design cleaner and more aligned with industry standards.

This is a non-critical suggestion to help you grow as a developer. Fantastic job overall!

✨ Please rate this review in the Platform's notification center¹. I will be grateful for your feedback! ✨

Rate AI review example ↩

mateacademy-ai-mentor · 2025-12-01T20:36:38Z

src/controllers/profile.controller.js

+const getProfile = async (req, res) => {
+  const { refreshToken } = req.cookies;
+
+  const user = await userService.getProfile(refreshToken);
+
+  res.send(userService.normalize(user));
+};
+
+const nameUpdate = async (req, res) => {
+  const { name } = req.body;
+  const { refreshToken } = req.cookies;
+
+  await userService.nameUpdate({ refreshToken, name });
+
+  res.sendStatus(200);
+};
+
+const emailUpdate = async (req, res) => {
+  const { password, newEmail, confirmEmail } = req.body;
+  const { refreshToken } = req.cookies;
+
+  await userService.emailUpdate({
+    refreshToken,
+    password,
+    newEmail,
+    confirmEmail,
+  });
+
+  res.sendStatus(200);
+};
+
+const passwordUpdate = async (req, res) => {
+  const { password, newPassword, confirmPassword } = req.body;
+  const { refreshToken } = req.cookies;
+
+  await userService.passwordUpdate({
+    refreshToken,
+    password,
+    newPassword,
+    confirmPassword,
+  });
+
+  res.sendStatus(200);
+};
+
+export const profileController = {
+  getProfile,
+  nameUpdate,
+  emailUpdate,
+  passwordUpdate,


While this implementation works, there's a good opportunity here to improve the application's design by changing how you handle user identity in authenticated routes.

Currently, every profile-related action relies on the refreshToken passed from the cookies to identify the user. However, the authMiddleware already validates an accessToken. The standard practice is to use the accessToken for authenticating the user for each request.

A better approach would be:

In your authMiddleware, after verifying the accessToken, decode it and attach the user's payload (e.g., id and email) to the req object, like req.user = userData;.

In this controller, instead of getting the refreshToken from cookies, you would get the user's ID from req.user.id.

Your service functions (getProfile, nameUpdate, etc.) would then accept the userId instead of the refreshToken.

This change would make your API more robust and align with standard practices, as the accessToken's primary role is to authorize requests, while the refreshToken's role is to generate new access tokens.

mateacademy-ai-mentor · 2025-12-01T20:36:38Z

src/middlewares/authMiddleware.js

+export const authMiddleware = async (req, res, next) => {
+  const authorization = req.headers['authorization'] || '';
+  const [, token] = authorization.split(' ');
+
+  if (!authorization || !token) {
+    throw ApiError.unauthorized();
+  }
+
+  const userToken = jwtService.verify(token);
+
+  if (!userToken) {
+    throw ApiError.unauthorized();
+  }
+
+  next();


This middleware correctly protects the route, which is great. To make it even more powerful and align with standard practices, you can attach the decoded user payload to the request object.

The jwtService.verify(token) function returns the user data that was signed into the token. You can assign this to req, for example: req.user = userToken; before calling next().

This way, any subsequent controller or middleware that runs after authMiddleware will have direct access to the authenticated user's information (like their ID) through req.user, which simplifies the logic in your controllers.

mateacademy-ai-mentor · 2025-12-01T20:36:39Z

src/services/user.service.js

+async function getProfile(refreshToken) {
+  const isValidToken = jwtService.verifyRefresh(refreshToken);
+
+  if (!isValidToken) {
+    throw ApiError.unauthorized();
+  }
+
+  const tokenData = await tokenService.findByToken(
+    refreshToken,
+    TOKEN_TYPES.REFRESH,
+  );
+
+  if (!tokenData || tokenData.expireAt < new Date()) {
+    throw ApiError.unauthorized();
+  }
+
+  const user = await User.findByPk(tokenData.userId);
+
+  if (!user) {
+    throw ApiError.unauthorized();
+  }
+
+  return user;
+}
+
+async function nameUpdate({ refreshToken, name }) {
+  const user = await getProfile(refreshToken);
+
+  user.name = name;
+  await user.save();
+}
+
+async function passwordUpdate({
+  refreshToken,
+  password,
+  newPassword,
+  confirmPassword,
+}) {
+  const user = await getProfile(refreshToken);
+
+  if (!(await bcrypt.compare(password, user.password))) {
+    throw ApiError.badRequest('Wrong password');
+  }
+
+  if (newPassword !== confirmPassword) {
+    throw ApiError.badRequest('Confirmation and password must be equal');
+  }
+
+  if (await bcrypt.compare(newPassword, user.password)) {
+    throw ApiError.badRequest(
+      'New password must be different from old password',
+    );
+  }
+
+  const hashedPassword = await bcrypt.hash(newPassword, 10);
+
+  user.password = hashedPassword;
+  await user.save();
+}
+
+async function emailUpdate({ refreshToken, password, newEmail, confirmEmail }) {
+  const user = await getProfile(refreshToken);
+  const isUsedEmail = await findByEmail(newEmail);
+
+  if (isUsedEmail) {
+    throw ApiError.badRequest('Email is already in use');
+  }
+
+  if (!(await bcrypt.compare(password, user.password))) {
+    throw ApiError.badRequest('Wrong password');
+  }
+
+  if (newEmail !== confirmEmail) {
+    throw ApiError.badRequest('Email confirmation does not match');
+  }
+
+  if (newEmail === user.email) {
+    throw ApiError.badRequest('New email must be different from old email');
+  }
+
+  const oldEmail = user.email;
+
+  user.email = newEmail;
+  await user.save();
+
+  const html = `
+  <h1>Your email ${oldEmail} has been changed to ${newEmail}</h1>`;
+
+  await emailService.send({
+    email: oldEmail,
+    subject: 'Your email has been changed',
+    html,
+  });


This set of profile management functions (getProfile, nameUpdate, passwordUpdate, emailUpdate) currently relies on the refreshToken to identify and authenticate the user for every action. This leads to some design issues:

Redundant Authentication: The getProfile function re-validates the refresh token, but this should be the responsibility of the authMiddleware using the accessToken.

Incorrect Token Usage: The primary purpose of an accessToken is to authorize requests like these. The refreshToken should only be used to get a new accessToken.

A more standard approach would be:

In authMiddleware, verify the accessToken and attach the user's decoded payload (e.g., { id: 1, email: '...' }) to req.user.

In the profileController, pass the user's ID (req.user.id) to the service functions.

Refactor these service functions to accept a userId instead of a refreshToken. For example, getProfile would become getProfile(userId) and would simply fetch the user with User.findByPk(userId).

This change improves the separation of concerns, uses tokens for their intended purposes, and makes the service layer cleaner and more focused on business logic.

auth app version #0.0.1

b814c6b

mateacademy-ai-mentor suggested changes Dec 1, 2025

View reviewed changes

bugfix, change login-refresh function, logout route middleware added,…

4fbdb79

… bugfix Apierror call

NickDevX requested a review from mateacademy-ai-mentor December 1, 2025 20:33

mateacademy-ai-mentor approved these changes Dec 1, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

auth app version #0.0.1 #205

auth app version #0.0.1 #205

Uh oh!

NickDevX commented Dec 1, 2025

Uh oh!

mateacademy-ai-mentor left a comment

Uh oh!

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Uh oh!

Uh oh!

mateacademy-ai-mentor left a comment

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

auth app version #0.0.1 #205

Are you sure you want to change the base?

auth app version #0.0.1 #205

Uh oh!

Conversation

NickDevX commented Dec 1, 2025

Uh oh!

mateacademy-ai-mentor left a comment

Choose a reason for hiding this comment

Review Summary

Footnotes

Uh oh!

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mateacademy-ai-mentor left a comment

Choose a reason for hiding this comment

Review Summary

Footnotes

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

mateacademy-ai-mentor Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants