DEF-024 — POST /login-with-email buries the auth token inside the user object

Backend
Medium severity
New
Defect DEF-024 — Severity: Medium · Status: New
Published

2026-06-17

DEF-024 — POST /login-with-email buries the auth token inside the user object

Summary

A successful login returns the auth token as user_access_token nested inside the user profile object, rather than as a clearly labelled top-level field. There is no token expiry timestamp in the response. This makes the token harder to locate, increases the chance of integration mistakes, and means clients have no way to know when a token will expire without testing it against the server.

Environment

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

Steps to Reproduce

  1. Send a successful POST /login-with-email request.
  2. Inspect the response body.

Expected Behaviour

The auth token should be returned as a clearly labelled top-level field in the response, separate from the user profile data. A token expiry timestamp should also be included so clients can manage session refresh proactively.

Actual Behaviour

oData is the full user profile object. The token is embedded inside it as user_access_token — indistinguishable at a glance from the dozens of other user fields. There is no expiry timestamp anywhere in the response:

{
  "status": "1",
  "message": "Loged in successfully",
  "oData": {
    "id": "199",
    "name": "Abdo",
    "email": "...",
    "user_access_token": "54ff94fa...",
    "user_email_otp": "",
    "user_phone_otp": "",
    ...40+ more fields...
  }
}

Additional Notes

  • The message contains a typo: "Loged in successfully" — should be "Logged in successfully".
  • The same response structure is returned by POST /verify-phone-otp (phone login) and POST /social-login, making this a systemic pattern rather than an isolated issue.

Impact

  • Clients must know to look for oData.user_access_token specifically — a non-obvious path
  • No token expiry means clients cannot refresh sessions proactively; they only discover expiry when a request fails with 401
  • Mixing credential/token data with profile data makes responses harder to parse and increases payload size on every login

Severity

Medium

Status

New

Reported By

QA / Testing Team