DEF-023 — Login endpoints couple authentication with device registration
DEF-023 — Login endpoints couple authentication with device registration
Summary
Both email login and phone login require fcm_token and device_type alongside the user’s credentials. These are device-registration fields that control push notification routing — they have no role in verifying who a user is. Mixing them into the login call means authentication is tightly coupled to the device, which breaks headless API access (automated testing, third-party integrations, server-to-server calls) and makes the endpoint harder to use correctly.
Affected Endpoints
POST /login-with-emailPOST /login-with-phone
Environment
- Platform: DriveLink Backend API
- Server:
https://project6.dxtserver.com/drivelink_new/public/api/v1 - Area: Authentication
- Requirement(s): FR-52 (Login — Email & Password), FR-53 (Login — Phone OTP)
- Date Reported: 2026-06-17
- Testing Phase: Backend API Testing
Steps to Reproduce
- Send
POST /login-with-emailwith only the user’s credentials:
{
"email": "user@example.com",
"password": "Password@2026"
}- Observe the response.
Expected Behaviour
Providing valid credentials (email + password) is sufficient to authenticate. Device registration is a separate concern and should either be optional or handled via a dedicated endpoint after login.
Actual Behaviour
The server rejects the request with a validation error:
{
"status": "0",
"message": "The fcm token field is required.",
"errors": {
"fcm_token": ["The fcm token field is required."],
"device_type": ["The device type field is required."]
}
}Workaround
Include fcm_token and device_type in every login request:
{
"email": "user@example.com",
"password": "Password@2026",
"fcm_token": "<firebase_token>",
"device_type": "ios"
}Impact
- Automated testing, CI pipelines, and server-to-server integrations cannot authenticate without constructing a fake device identity
- Any client that doesn’t have a Firebase FCM token at login time (e.g., web clients, scripts) is completely blocked
- The same coupling exists on
POST /register(see DEF-025) - A dedicated
POST /update_user_device_tokenendpoint already exists — device token updates should go there, not be forced into login
Severity
Medium
Status
New
Reported By
QA / Testing Team