Include U.S. territories in allowed countries for IdV phone#7016
Include U.S. territories in allowed countries for IdV phone#7016mitchellhenke merged 18 commits intomainfrom
Conversation
changelog: Bug Fixes, Identity Verification, Allow U.S. territory numbers for IdV phone step
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
app/services/phone_country_codes.rb
Outdated
| class PhoneCountryCodes | ||
| US_AND_US_TERRITORY_CODES = ['AS', 'GU', 'MP', 'PR', 'US', 'VI'] | ||
| end |
There was a problem hiding this comment.
I wish we had a better home for this constant, but I can't think of one... PhoneNumberCapabilities maybe since it has INTERNATIONAL_CODES?
There was a problem hiding this comment.
I think I'm going to convert this into a config item? PhoneNumberCapabilities makes sense to me too
There was a problem hiding this comment.
Config makes sense to me too, maybe even generalized to “supported IDV address verification country codes”.
| end | ||
|
|
||
| def user_phone? | ||
| MfaContext.new(current_user).phone_configurations.any? { |config| config.phone == idv_phone } |
There was a problem hiding this comment.
do we want to make sure idv_phone and config.phone are both formatted/normalized when we compare?
There was a problem hiding this comment.
| 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 } |
There was a problem hiding this comment.
This method was pulled (mostly) verbatim from another class, FWIW.
There was a problem hiding this comment.
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)
* 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>
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) { |
There was a problem hiding this comment.
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;
}
// ...
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 |
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) |
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:
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:
513555123493955501373065551234Steps:
Context: