fix: bind password reset to verified OTP token

[hariom888]

Summary

Fixes #1539.

This PR strengthens the password reset flow by preserving the OTP verification result and forwarding a short-lived reset token to the password reset endpoint.

Previously, the frontend discarded the response from /user/verifyOtp and only navigated to NewPasswordScreen with the user's email. The password reset request therefore contained only:

• email
• newPassword

which provided no cryptographic proof that the OTP had actually been verified.

Changes

• Updated useVerifyOtpMutation to return the full API response instead of only the message string.
• Added a typed VerifyOtpResponse containing:
  • message
  • resetToken
• Updated OtpScreen to forward the resetToken when navigating to NewPasswordScreen.
• Updated useChangePasswordMutation to include resetToken in the password reset request.
• Updated NewPasswordScreen to require a valid resetToken before allowing password reset.
• Updated navigation parameters to include resetToken.

Security Improvement

This change creates a frontend binding between successful OTP verification and password reset by ensuring that the password update request carries a reset credential produced during OTP verification.

The frontend now expects the backend to issue a short-lived, single-use reset token after successful OTP verification and validate that token before changing the user's password.

Testing

• Verified OTP verification returns a reset token.
• Verified navigation passes the reset token to the password reset screen.
• Verified password reset requests include the reset token.
• Verified password reset cannot proceed without a reset token.

[github-actions]

Thank you @, for creating the PR and contributing to our UltimateHealth project 💗.
Our team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

[github-actions]

Automated Review Feedback

Provide actionable comments grouped by severity:

Important

• Missing Automated Tests for Security Flow: The PR introduces a critical security enhancement to the password reset flow. While manual testing steps are provided, automated unit or integration tests are crucial to ensure the resetToken validation logic in NewPasswordScreen (e.g., the useEffect hook) and the correct passing of the token through the mutations are robust and do not regress in future changes. This is especially important for security-sensitive features.

Suggestions

• Improve Type Safety for Navigation Parameters: Consider defining a specific type for the route.params in NewPasswordScreenProp (and potentially OtpScreenProp) to explicitly declare email and resetToken. This enhances type safety and readability, making it clearer what parameters are expected.

  // Example for NewPasswordScreen
  type NewPasswordScreenRouteParams = {
      email: string;
      resetToken: string;
  };
  
  type NewPasswordScreenProp = NativeStackScreenProps<
      AuthStackParamList,
      'NewPasswordScreen'
  >;
  // Then use route: RouteProp<AuthStackParamList, 'NewPasswordScreen'> & { params: NewPasswordScreenRouteParams }
  // or similar, depending on your navigation setup.

• Refine AxiosError Type: The AxiosError type is currently any. For better type safety and more precise error handling, consider defining a more specific type for AxiosError if your backend returns structured error responses (e.g., AxiosError<BackendErrorResponse>).

Maintainer Note:

Once the initial automated feedback has been addressed, maintainer @SB2318 will review the pull request for final evaluation.