DEF-027 — Forgot password flow is internally broken: the two steps use different field names for the same value

Backend
High severity
New
Defect DEF-027 — Severity: High · Status: New
Published

2026-06-17

DEF-027 — Forgot password flow is internally broken: the two steps use different field names for the same value

Summary

The forgot-password flow is a two-step process: request a reset code, then verify it. Step 1 (POST /forgot-password) returns the reset code under the key password_reset_code. Step 2 (POST /reset-password-otp-verify) expects that same value but under a completely different key named otp. The two steps don’t connect — passing the value from step 1 directly into step 2 fails silently because the field name doesn’t match.

Environment

  • Platform: DriveLink Backend API
  • Server: https://project6.dxtserver.com/drivelink_new/public/api/v1
  • Area: Authentication / Password Reset
  • Requirement(s): FR-26 (Forgot Password)
  • Date Reported: 2026-06-17
  • Testing Phase: Backend API Testing

Steps to Reproduce

  1. Call POST /forgot-password with a registered email:
{ "email": "user@example.com" }

Response includes:

{ "oData": { "password_reset_code": "be38a44de161..." } }
  1. Use the returned value in POST /reset-password-otp-verify, passing it under the name given in step 1:
{
  "email": "user@example.com",
  "password_reset_code": "be38a44de161..."
}
  1. Observe the response.

Expected Behaviour

The value from step 1 is accepted in step 2. The flow connects end-to-end without requiring the user or developer to know that the field must be renamed between steps.

Actual Behaviour

Step 2 ignores password_reset_code entirely and returns:

{
  "status": "0",
  "message": "The otp field is required."
}

The correct call must rename the value to otp:

{
  "email": "user@example.com",
  "otp": "be38a44de161..."
}

Impact

  • The forgot-password flow is broken for any client that follows the natural path of using the field name returned by step 1
  • FR-26 (Password Reset/Recovery) is already flagged as a production blocker — this internal inconsistency means the flow would remain broken even if the OTP delivery is fixed
  • The mismatch is entirely server-side and cannot be worked around without knowing the hidden field name in advance

Severity

High

Status

New

Reported By

QA / Testing Team