Currently, SMS Framework 8.x-1.x integrates with Telephone field and has a number ownership verification system of it's own. To create less confusion, it should be decided where and how to implement the verification in a single place, with sms functionality relying on SMS Framework and mobile number validation relying on Mobile Number module as a field type.

Similarities between the two methods:

  • Secret code sent to user
  • Code expiration
  • Flood management

Differences in Mobile Number implementation:

  1. Codes are tokenized, hashed, and are entity/phone number agnostic, although hashed code uses phone number as part of salt
  2. Verification status is saved as a property in the mobile number field
  3. Verification ability does not apply to telephone fields
  4. Verification is allowed inline with ajax
  5. Verification is part of field validation (verification requirement), supporting entity validation
  6. Verification settings stored in field settings
  7. Flood is per phone number

Differences in SMS Framework implementation:

  1. Code is saved as part of a custom entity that reference other entities where telephone fields are used (PhoneNumberVerification), relies on dynamic entity reference.
  2. Verification status is saved in the custom entity along with phone number, same entity used for storing codes (PhoneNumberVerification)
  3. Extends telephone field
  4. Verification ('confirmation') happens on a separate form
  5. Verification is not part of field validation
  6. Verification settings saved in config entities
  7. Flood is per session
  8. Allows finding verification status and code through views, or anything relying on entity api.

Comments

nyariv created an issue.

dpi’s picture

dpi
Location Perth, Australia
commented

Number validation

I had in mind that SMS Framework would use the standard telephone field, and rely on modules such as (or similar to) telephone_validation.

Metadata

I think the only reason the field should fail is if the phone number is unacceptable for some reason, it shouldn't restrict editing the entity in any way.

Verification code

Codes are tokenized, hashed, and are entity/phone number agnostic, although hashed code uses phone number as part of salt

As a part of creating the SMS Framework phone number verification system, I proposed adding a verification code generator system (see #2643692: SMS User Redesign: "Verification Code System"). However this is was and is still low priority. We can reach parity, if this is indeed a desirable requirement.

dpi’s picture

dpi
Location Perth, Australia
commented

country - you cannot extract country from value easily which indeed requires a service, but that would not work well with views when you want to filter by country. (Comment
)

You can derive the country for the phone number in multiple ways:

  • A country field on the entity
  • Timezone, if the entity is a user, and the timezone is sufficiently localized.
  • If the phone number is in E.164 format.

I dont have any other point other than to say it can be done dynamically when required. If the country needs to be Views-able then making use of a country field would be ideal if possible.

nyariv’s picture

nyariv commented

It's not just with views, also rules, token, etc.

You can derive the country for the phone number in multiple ways:

If country/timezone is a separate field then it can not be assured to belong to the origin of the number. You may have entities with multiple telephone fields, and you will need to match each one with its country field, and handling multi value fields would be a nightmare.

The country attribute just needs to be coupled with the number value. It could be argued that local_number and country together should replace value (E164), but again it would require computation every time you wanted to use the full number, which is not good for views/rules/etc.

nyariv’s picture

nyariv commented

It's like saying the address module should contain only one string value for the full address and all attributes (city, street, etc) would be computed when needed.

nyariv’s picture

nyariv commented

I had in mind that SMS Framework would use the standard telephone field, and rely on modules such as (or similar to) telephone_validation.

I believe verification should be part of validation, it is optional for Mobile Number, and when used with combination of uniqueness validation it allows giving the field a more valuable purpose, such as identifying a user by mobile number or two factor authentication.

I think the only reason the field should fail is if the phone number is unacceptable for some reason, it shouldn't restrict editing the entity in any way.

There are some cases where you want to prevent saving an entity if number is not verified.

  • When used as a unique value field, you don't want others to claim the number unless they can verify it is their own, especially when added to user entities
  • For anti spam bot protection
  • For data quality, where you want to have values of only callable verified numbers.
  • For when contact credentials are crucial and need to validated. Emails have such mechanism, such as drupal's registration activation email, it's multistep activation process creates accounts in limbo if not validated. But sms's instant and "offline" response, and high availability, allows verifying the numbers inline to the field.
  • ...
dpi’s picture

dpi
Location Perth, Australia
commented

Take a look at #2797121: Separate entity phone number from verification service for flexibility.