LG-126 - Validate the appearance of phone numbers before allowing OTP submission

[jgsmith-usds]

Why: We want to be able to leverage several phone validation options,
so we are (1) moving the validation to the backend, (2) giving feedback
to the user when the phone number is considered valid, (3) enabling
"Send Code" only when the phone number is considered valid.

How: Originally, we were going to send a POST to an endpoint, but since we
already have libphonenumber-js in our browser-side environment, we're using that
until we need to do validation that can't be done in the browser. Since this isn't the
final validation, we do this just for the benefit of the UX.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated.

[monfresh]

I was out last week, so I'm probably missing some context. Could you please explain what problem prompted this PR? Is it to enhance the user experience so that they get feedback about the validity of a phone number faster than before? Was there anything wrong with the server side validation that was already in place, via the phony_rails gem (see app/validators/form_phone_validator)?

I see this is still a work in progress, but wanted to offer some initial thoughts. It looks like we are now using Phonelib for the client-side validation, but still using phony_rails in the backend. If the two libraries perform validation differently, this could lead to confusion if one thinks a number is valid and the other doesn't. Should we choose one gem for consistency?

Also, having the controller in the verify namespace confused me because I thought this was only meant for IdV, but it looks like it's meant to apply globally, right?

[jgsmith-usds]

I put it in the same space as the other controllers for account verification. As far as I can tell, the phone number is entered as part of the account creation flow and later when a person changes their phone number. I'm trying to follow the patterns I'm seeing elsewhere, but I'm open to changing them.

For now, doing validation through an endpoint doesn't get us anything, so we could replace the call to the endpoint with a call to the JavaScript library that's bundled with the page. The primary goal is to disable the submit button until we have what looks like a valid phone number. Secondary is to have an additional visual indicator that the phone number looks good (e.g., a check mark next to the phone field).

As far as Phonelib vs. phony_rails: I'm using whichever library I found already used in the Ruby code (e.g.,

identity-idp/app/forms/user_phone_form.rb

Line 11 in 29b4210

self.international_code = Phonelib.parse(phone).country || PhoneFormatter::DEFAULT_COUNTRY

)

[monfresh]

@jgsmith-usds The verify namespace in our app refers to Identity Verification specifically. Setting up your phone number during LOA1 account creation, or changing the phone number of an existing LOA1 account does not fall under the verify namespace.

[jgsmith-usds]

@monfresh Thanks for the clarification. For this PR, I've removed all of the backend since we aren't doing anything that can't be handled by the libraries already included in the frontend.

[jmhooper]

What is the purpose of adding / removing these classes here?

[jgsmith-usds]

For this PR, this is a pre-optimization. I was planning to add CSS styles to add an indicator following the input field using those classes to manage it, but in review, it looked like there was enough useful in this PR as it is without waiting on that. I'll remove the classes for this PR and put them back in when I get the CSS ironed out.

[jmhooper]

Cool, my next question was about how the user is supposed to determine why the "Send Code" button is disabled, but I suppose that is coming later.

[jgsmith-usds]

-nod- -- I'm not sure I want to show an error message when they're still entering their phone number, but we could do something on-blur if the number doesn't look valid. That might be a better next step before I get the CSS whipped up since we already have a mechanism for doing messaging like that.