Invalid Phone Numbers Accepted: A Bug Report

by Admin 45 views
Invalid Phone Numbers Accepted: A Bug Report

Hey guys! Today, we're diving deep into a critical yet often overlooked aspect of app development: phone number validation. Specifically, we're dissecting a bug report that highlights how a certain application fails to properly validate phone numbers, leading to a cascade of potential issues. So, grab your favorite beverage, and let's get started!

Summary

The issue at hand revolves around an application's lax handling of phone number inputs during both the addition and editing of contacts. Instead of enforcing a strict format—particularly crucial in contexts like Singapore where phone numbers are uniformly 8 digits long—the app merrily accepts all sorts of numeric (and sometimes even non-numeric!) strings. This cavalier approach severely degrades data quality and introduces unreliability into search, filtering, and export functionalities. It's like building a house on a shaky foundation; sooner or later, things are bound to crumble.

Steps to Reproduce

To illustrate this problem, here’s a step-by-step guide on how to reproduce the bug:

  1. Launch the app: Make sure you’re looking at the main contact list.
  2. Add a contact with a short phone number: Use the command add n/Test Short p/123 e/short@ex.com a/1 Road.
  3. Add a contact with an overly long phone number: Try add n/Test Long p/12345678901 e/long@ex.com a/2 Road.
  4. (If allowed) Add a contact with non-numeric characters: Input add n/Test NonNumeric p/123-456 e/nonnum@ex.com a/3 Road.
  5. Edit an existing contact: Use edit 1 p/12 to change the phone number to something invalid.
  6. Observe the outcome: Check if the commands succeed and how the phone number is displayed and stored.

Expected Behavior

So, what should actually happen when a user tries to input an invalid phone number? Here’s the rundown:

  • Enforce validation rules: The app must have robust phone number validation rules in place.
  • Singapore-specific validation (if applicable):
    • Accept only 8-digit numbers: No more, no less.
    • Optionally restrict the leading digit: Consider limiting the first digit to 3, 6, 8, or 9, as is common in Singapore.
  • International considerations (if applicable):
    • Minimum constraints: At the very least, enforce a numeric-only constraint and a reasonable length range.
    • Country code format: Alternatively, require a country code format like E.164, providing clear instructions to the user.
  • Specific error messages: For any invalid input, the app should throw a clear, field-specific error message, such as:
    • “Invalid phone number: must be an 8-digit Singapore number (starting with 3/6/8/9).”
    • “Invalid phone number: numbers only, length must be 8–15 digits (or use +countrycode).”

Actual Behavior

Unfortunately, the current behavior is far from ideal. The app cheerfully accepts phone numbers that are too short (e.g., “123”), too long, and even those with non-numeric characters. There's no validation error to be seen, and contacts are happily created or updated with these invalid phone values. It's like the app is turning a blind eye to data integrity!

Image

Here’s a visual representation of the issue:

[Image of the bug]

Impact

The consequences of this lax validation are far-reaching:

  • Data integrity: Invalid phone numbers significantly reduce the usefulness of the system for outreach and follow-ups. Imagine trying to call someone with a 3-digit phone number!
  • Usability: Users can't trust the phone fields for calling or exporting to dialers/SMS systems. This erodes confidence in the application.
  • Downstream errors: Exports, imports, and integrations may fail or require extensive data cleaning. This adds unnecessary overhead and complexity.
  • Analytics and deduplication: Weak validation increases the likelihood of duplicates and mismatches in logs and statistics. This skews data and makes accurate analysis difficult.

Likely Root Cause (inference)

So, what’s the likely culprit behind this mess? Here are a few educated guesses:

  • Insufficient validation: The parser or model layer likely doesn't validate the phone field beyond simply checking for its presence. Alternatively, it might be using a permissive regex that allows any digits (and possibly symbols) of any length.
  • Lack of canonicalization: The phone model probably lacks a canonicalization step, such as stripping spaces or dashes, followed by strict validation. It's like trying to judge a book by its cover without even opening it.

Recommendation

Fear not! Here’s a comprehensive plan to tackle this issue head-on:

  1. Define the scope: First, decide whether the app is targeting Singapore-only numbers or an international audience. This decision will dictate the validation rules.
  2. If SG-only:
    • Enforce 8-digit numbers: Strictly accept only 8-digit numbers.
    • Optionally enforce the leading digit: Consider restricting the first digit to 3, 6, 8, or 9.
    • Reject invalid inputs: Reject anything else with a clear, field-specific error message. Don't leave the user guessing!
  3. If international:
    • Enforce numeric-only (or “+” followed by digits): Ensure that the input is either numeric-only or starts with a “+” followed by digits.
    • Enforce a reasonable length range: Set a reasonable length range, such as the E.164 standard (up to 15 digits).
    • Provide clear guidance: Offer clear instructions in the error message and in the user guide. Help the user understand the requirements.
  4. Normalize on input: Strip spaces, dashes, and parentheses before validation. However, reject the input if the final numeric form is invalid. This ensures consistency and reduces errors.
  5. Add tests and update documentation: Implement field-level and parser tests to verify the validation rules. Update the user guide to document the rules and provide examples. This ensures that the fix is robust and well-understood.

Add Tests

Here are some specific test cases to implement:

  • add with p/123: Should reject with a specific phone error.
  • add with p/1234567: Should reject (7 digits).
  • add with p/12345678: Should accept (if SG rule), otherwise validate per chosen policy.
  • add with p/02345678: Should reject if enforcing {3,6,8,9} leading digit; accept otherwise.
  • add with p/+6512345678: Should accept if international/E.164 policy; reject if SG-only policy.
  • add with p/123-45678: Should accept only if normalization + post-normalization validation passes; otherwise reject.
  • edit 1 p/12: Should reject with a specific phone error.
  • Bulk import/export: Invalid numbers should either be rejected with clear errors or normalized according to the defined policy.

Why This Qualifies as a Bug

  • Type: FunctionalityBug: Allowing typos in phone numbers can lead to future errors when referencing those numbers.
  • Severity: Low: While not critical, this flaw can affect normal operations, especially when user input is incorrect. It causes a minor inconvenience and potential for future errors.

Labels

severity.Low type.FunctionalityBug

In conclusion, properly validating phone numbers is essential for maintaining data integrity and ensuring a reliable user experience. By implementing the recommendations outlined above, developers can prevent a multitude of issues and build a more robust and user-friendly application. Keep coding, and stay sharp!