starred/twofactor_gateway-nextcloud

Fork 0

mirror of https://github.com/nextcloud/twofactor_gateway.git synced 2026-04-25 09:05:55 +03:00

[GH-ISSUE #327] Phone number verification - Need to specify country code. #72

New issue

Open

opened 2026-02-26 05:32:50 +03:00 by kerem · 8 comments

kerem commented

2026-02-26 05:32:50 +03:00

Owner

Originally created by @nolsen42 on GitHub (Feb 25, 2020).
Original GitHub issue: https://github.com/nextcloud/twofactor_gateway/issues/327

Certain SMS services (at least with sms77.io) will send SMS messages to the wrong person if the user doesn't specify their country code, which is a common thing to omit when entering their number. It'd be a good idea if the app specifically tells you to enter a country code, or a dropdown box with all the country codes of the world.

Originally created by @nolsen42 on GitHub (Feb 25, 2020). Original GitHub issue: https://github.com/nextcloud/twofactor_gateway/issues/327 Certain SMS services (at least with sms77.io) will send SMS messages to the wrong person if the user doesn't specify their country code, which is a common thing to omit when entering their number. It'd be a good idea if the app specifically tells you to enter a country code, or a dropdown box with all the country codes of the world.

kerem added the

help wanted

1. to develop

labels

2026-02-26 05:32:50 +03:00

kerem commented

2026-02-26 05:32:50 +03:00

Author

Owner

@ChristophWurst commented on GitHub (Feb 25, 2020):

This is hard to implement because we support so many providers. And everyone of them has their own format, unfortunately.

@ChristophWurst commented on GitHub (Feb 25, 2020): This is hard to implement because we support so many providers. And everyone of them has their own format, unfortunately.

kerem commented

2026-02-26 05:32:50 +03:00

Author

Owner

@cdjenkins commented on GitHub (Jun 1, 2020):

One option is to have all number in E.164 format (which specifies the country code): https://developers.omnisend.com/guides/e164-phone-number-formatting
https://support.plivo.com/support/solutions/articles/17000042303-do-i-need-to-add-country-code-while-dialling-out-

@cdjenkins commented on GitHub (Jun 1, 2020): One option is to have all number in E.164 format (which specifies the country code): https://developers.omnisend.com/guides/e164-phone-number-formatting https://support.plivo.com/support/solutions/articles/17000042303-do-i-need-to-add-country-code-while-dialling-out-

kerem commented

2026-02-26 05:32:50 +03:00

Author

Owner

@ChristophWurst commented on GitHub (Jun 2, 2020):

Yet we'd then have to convert it into the format the the specific provider excepts, right?

@ChristophWurst commented on GitHub (Jun 2, 2020): Yet we'd then have to convert it into the format the the specific provider excepts, right?

kerem commented

2026-02-26 05:32:51 +03:00

Author

Owner

@cdjenkins commented on GitHub (Jun 2, 2020):

Option #1) Only accept E.164 or few acceptable formats. No need to accept 10 number formats.
Option #2) Have each app handle phone number formats specific to itself

@cdjenkins commented on GitHub (Jun 2, 2020): Option #1) Only accept E.164 or few acceptable formats. No need to accept 10 number formats. Option #2) Have each app handle phone number formats specific to itself

kerem commented

2026-02-26 05:32:51 +03:00

Author

Owner

@ChristophWurst commented on GitHub (Jun 3, 2020):

In terms of UI complexity I'd favor option 1 because we can focus on one format. Then each of the providers can convert the number into any other format if necessary.

@ChristophWurst commented on GitHub (Jun 3, 2020): In terms of UI complexity I'd favor option 1 because we can focus on one format. Then each of the providers can convert the number into any other format if necessary.

kerem commented

2026-02-26 05:32:51 +03:00

Author

Owner

@boppy commented on GitHub (Jun 3, 2020):

In terms of UI complexity I'd favor option 1 because we can focus on one format. Then each of the providers can convert the number into any other format if necessary.

Absolutely! And E.164 is commonly used and known (not the name, but the format ;-))... Question is validation. I'm in for ^\+?[1-9]\d{1,14}$ (src) as storage regex and ^\+?[1-9][\d\s]{1,20}$ for User Input.

@boppy commented on GitHub (Jun 3, 2020): > In terms of UI complexity I'd favor option 1 because we can focus on one format. Then each of the providers can convert the number into any other format if necessary. Absolutely! And E.164 is commonly used and known (not the name, but the format ;-))... Question is validation. I'm in for `^\+?[1-9]\d{1,14}$` ([src](https://stackoverflow.com/a/23299989/1985204)) as storage regex and `^\+?[1-9][\d\s]{1,20}$` for User Input.

kerem commented

2026-02-26 05:32:51 +03:00

Author

Owner

@j-ed commented on GitHub (Jun 3, 2020):

If you create any input check you should have in mind that countries exist, like e.g. Liechtenstein, where no area codes exist. A number is formatted like this: +423 99887766 😉

@j-ed commented on GitHub (Jun 3, 2020): If you create any input check you should have in mind that countries exist, like e.g. Liechtenstein, where no area codes exist. A number is formatted like this: +423 99887766 😉

kerem commented

2026-02-26 05:32:51 +03:00

Author

Owner

@boppy commented on GitHub (Jun 3, 2020):

If you create any input check you should have in mind that countries exist, like e.g. Liechtenstein, where no area codes exist. A number is formatted like this: +423 99887766 😉

Yes, that's why I don't like any "advanced" check. The Regex pasted just ensures that

Number starts with an optional + (we might/should make this required to avoid problems)
First digit is not 0
1 to 14 digits follow

All this, for sure, tbd.

@boppy commented on GitHub (Jun 3, 2020): > If you create any input check you should have in mind that countries exist, like e.g. Liechtenstein, where no area codes exist. A number is formatted like this: +423 99887766 😉 Yes, that's why I don't like any "advanced" check. The Regex pasted just ensures that * Number starts with an optional `+` (we might/**should** make this required to avoid problems) * First digit is not 0 * 1 to 14 digits follow All this, for sure, tbd.

kerem referenced this issue

2026-02-26 05:33:53 +03:00

[PR #72] [MERGED] Bump webpack from 4.16.1 to 4.16.2 #190

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/twofactor_gateway-nextcloud#72

No description provided.

Rows
Columns