Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile Number Validation Bug: Invalid Numbers Passing Validation #2591

Open
DraKen0009 opened this issue Nov 10, 2024 · 10 comments
Open

Mobile Number Validation Bug: Invalid Numbers Passing Validation #2591

DraKen0009 opened this issue Nov 10, 2024 · 10 comments

Comments

@DraKen0009
Copy link
Contributor

DraKen0009 commented Nov 10, 2024

Describe the bug
The mobile number validation allows invalid phone numbers like +000000000000 and +9876543210123456, which ideally should not be considered valid. This issue is due to a bug in the regular expression used in the validation logic.

To Reproduce
Steps to reproduce the behavior:

  1. Go to the mobile number validation function located here.
  2. Try validating phone numbers like +000000000000 or +9876543210123456.
  3. Observe that these numbers are incorrectly validated as valid.

Expected behavior
Phone numbers with formats like +000000000000 and overly long sequences like +9876543210123456 should not pass validation.

Additional context
This issue seems to be caused by the current regex pattern: regex link.

@DraKen0009
Copy link
Contributor Author

I think we should add some proper validations instead of using regex pattern bcz

  1. Stricter regex fails for some valid numbers
  2. Simpler regex validates the invalid numbers

cc: @sainak

@JohnLu2004
Copy link
Contributor

Hi @vigneshhari, I see that PR #2588 has been merged into main. Should this GitHub issue be closed?

@DraKen0009
Copy link
Contributor Author

@JohnLu2004 It was removed from the scope of #2588 , this issue need to be solved separately.

@JohnLu2004
Copy link
Contributor

Hi @DraKen0009 , Thanks for the follow-up. Could I be assigned this issue then? I'll use your comment as guidelines on how to properly validate

@DraKen0009
Copy link
Contributor Author

@JohnLu2004 I'll suggest you to write down your approach and get it approve first before working on it.

@JohnLu2004
Copy link
Contributor

I've been checking out the issue and thinking about potential approaches to this issue. How do you feel about this approach on a high level?:

Use a carrier lookup service to check whether the phone number is assigned to an active carrier. The overhead would be paying for a monthly service though. There are free tiers, but we would easily go over the monthly limit.

We could also try OTP, but I think we would run into issues if a medical staff is entering in someone's phone number instead of the person themselves.

@ayushsaini7717
Copy link

@DraKen0009 @Jacobjeevan I've been checking out the current regex pattern and i found that their is some issues on Indian mobile number regex and international mobile number regex(inefficient and overly complex) , i can simplify them to work better . Should i start working on this issue.

@DraKen0009
Copy link
Contributor Author

@ayushsaini7717 it's better to write down your approach if you have one , when asking to be assigned

@ayushsaini7717
Copy link

@DraKen0009 the current regex allows invalid numbers like +000000000000 or overly long ones, So Update the validation logic to enforce stricter rules may be a good approach in which numbers should start with '+', then having a valid country code and the last not be all zeroes and have a maximum of 15 digits with more efficient regix pattern.

@DraKen0009
Copy link
Contributor Author

I'll suggest you to come up with the regex pattern first, bcz I did tried to use multiple patterns but wasn't able to find a acceptable solution.

So try to come up with some regex, test it out thoroughly and let us know the results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants