Skip to content

Include U.S. territories in allowed countries for IdV phone#7016

Merged
mitchellhenke merged 18 commits intomainfrom
aduth-pr-phone-step
Sep 23, 2022
Merged

Include U.S. territories in allowed countries for IdV phone#7016
mitchellhenke merged 18 commits intomainfrom
aduth-pr-phone-step

Conversation

@aduth
Copy link
Contributor

@aduth aduth commented Sep 22, 2022

Why: Since the restriction for phone step is based on the assumption that address verification is only supported for U.S. numbers, and U.S. numbers should include U.S. territories.

Screenshots:

Before After
image image

Testing Instructions:

Confirm that you can use a U.S. mainland phone number or a U.S. territory phone number at the "Phone" step of the identity verification flow, and not another international phone number.

Sample phone numbers:

  • U.S. mainland: 5135551234
  • Puerto Rico: 9395550137
  • Canada: 3065551234

Steps:

  1. Navigate to http://localhost:3000
  2. Sign in or create an account
  3. Navigate to http://localhost:3000/verify
  4. Complete proofing process up to "Enter a phone number with your name on the plan"
  5. Enter a phone number and click Continue
  6. Observe there is no validation preventing you from continuing to delivery method selection, unless using a non-U.S. number
  7. Observe that only applicable delivery methods are shown for delivery method selection (i.e. only SMS for Puerto Rico)

Context:

@aduth aduth marked this pull request as ready for review September 22, 2022 18:23
@aduth aduth requested a review from a team September 22, 2022 18:23
Conflicting variable name in "#new", not necessary anyways since we use it once in assignment, and helps collapse lines
We now support multiple. "valid country" should apply based on the selected country code regardless of how many countries are supported
Copy link
Contributor

@zachmargolis zachmargolis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +1 to +3
class PhoneCountryCodes
US_AND_US_TERRITORY_CODES = ['AS', 'GU', 'MP', 'PR', 'US', 'VI']
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish we had a better home for this constant, but I can't think of one... PhoneNumberCapabilities maybe since it has INTERNATIONAL_CODES?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm going to convert this into a config item? PhoneNumberCapabilities makes sense to me too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Config makes sense to me too, maybe even generalized to “supported IDV address verification country codes”.

Copy link
Contributor

@mitchellhenke mitchellhenke Sep 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed and made configurable in 37b286e

end

def user_phone?
MfaContext.new(current_user).phone_configurations.any? { |config| config.phone == idv_phone }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to make sure idv_phone and config.phone are both formatted/normalized when we compare?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
MfaContext.new(current_user).phone_configurations.any? { |config| config.phone == idv_phone }
MfaContext.new(current_user).phone_configurations.any? { |config| config.formatted_phone == Phonelib.parse(idv_phone).international }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method was pulled (mostly) verbatim from another class, FWIW.

Copy link
Contributor

@eric-gade eric-gade left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might want to be careful doing live child dom queries in the connectedCallback without first checking if this.isConnected is true. It used to be the case -- and still might be -- that the child content is not guaranteed to be parsed at connect time, and also, hilariously, that connectedCallback can be called when the element is already disconnected (!!)

(Some more info here)

@mitchellhenke mitchellhenke merged commit 5d9ec6a into main Sep 23, 2022
@mitchellhenke mitchellhenke deleted the aduth-pr-phone-step branch September 23, 2022 15:49
mitchellhenke pushed a commit that referenced this pull request Sep 23, 2022
* Include U.S. territories in allowed countries for IdV phone

changelog: Bug Fixes, Identity Verification, Allow U.S. territory numbers for IdV phone step

* Use form instance for allowed countries

* Only validate unsupported delivery methods if all unsupported

* limit delivery options to phone number capabilities

* Add regression coverage for "valid_phone_for_allowed_countries?" fix

* Add test coverage for updated all-method-unsupported logic

* Add test coverage for conditional field visibility

* Check confirmed phones for PhoneNumberCapabilities initializer

* Remove unnecessary memoization

Conflicting variable name in "#new", not necessary anyways since we use it once in assignment, and helps collapse lines

* Update spec expected error message for unsupported country

* Fix OTP delivery method re-render on invalid create

* Validate region regardless of number of supported countries

We now support multiple. "valid country" should apply based on the selected country code regardless of how many countries are supported

* Update server-side logic for U.S. number constraint error message

* Fix empty errors value in spec assertion

* Add phone analytics to phone finder

* rename address proofing country codes constant and make it configurable

* fix specs

* JavaScript this.isConnected fix

Co-authored-by: Mitchell Henke <mitchell.henke@gsa.gov>
@aduth
Copy link
Contributor Author

aduth commented Sep 26, 2022

You might want to be careful doing live child dom queries in the connectedCallback without first checking if this.isConnected is true. It used to be the case -- and still might be -- that the child content is not guaranteed to be parsed at connect time, and also, hilariously, that connectedCallback can be called when the element is already disconnected (!!)

(Some more info here)

That's good to know. This component has been deployed for quite some time now and I haven't seen any errors surface in NewRelic related to this. I see that MDN mentions a warning about this, but it's not clear when that would actually happen. Do you have any more specific details?

if (!this.textInput || !this.codeInput) {
return;
}
if (this.isConnected) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from understanding whether this is truly necessary, we could have avoided indenting the whole function by implementing this as an early return instead.

if (!this.isConnected) {
  return;
}

// ...

@eric-gade
Copy link
Contributor

You might want to be careful doing live child dom queries in the connectedCallback without first checking if this.isConnected is true. It used to be the case -- and still might be -- that the child content is not guaranteed to be parsed at connect time, and also, hilariously, that connectedCallback can be called when the element is already disconnected (!!)
(Some more info here)

That's good to know. This component has been deployed for quite some time now and I haven't seen any errors surface in NewRelic related to this. I see that MDN mentions a warning about this, but it's not clear when that would actually happen. Do you have any more specific details?

The way it's currently used, we should not see any issues. However, if this component is re-used in a different context where it might be moved around (perhaps as part of a React application, etc) there is a chance we could run into trouble. From what I recall it's a timing issue. I have not seen it in a long time because I have followed the convention, but it can be a hair-tearing bug to deal with if you don't know about it

@aduth
Copy link
Contributor Author

aduth commented Sep 26, 2022

However, if this component is re-used in a different context where it might be moved around (perhaps as part of a React application, etc) there is a chance we could run into trouble.

I would be very interested to see a proof-of-concept demo of the issue. From what I've been able to find in my searches, it seems like it would only ever be an issue in the case that the element removed itself from the DOM as part of its own initialization, which is quite an edge-case and I'd assume would be easy to identify in a component's own logic.

(And just to clarify, I'm not trying to cast doubt, I just really want to understand the circumstances of the issue more clearly)

@solipet solipet mentioned this pull request Sep 26, 2022
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

Successfully merging this pull request may close these issues.

5 participants