Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change in persisting phone number. #83

Merged
merged 22 commits into from
Oct 28, 2020
Merged

Conversation

binh-dam-ibigroup
Copy link
Collaborator

@binh-dam-ibigroup binh-dam-ibigroup commented Oct 8, 2020

Checklist

  • Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
  • Any modified or new methods or classes have helpful JavaDoc and code is thoroughly commented
  • The description lists all applicable issues this PR seeks to resolve
  • [na] The description lists any configuration setting(s) that differ from the default settings
  • All tests and CI builds passing

Description

This PR fixes #79.

Per team discussion, the /api/secure/user/<id>/verify_sms GET endpoint (for requesting an SMS) now takes a phone number as path parameter and persists that number as the user's phone number. It also sets isPhoneNumberVerified = false and notificationChannel = "sms" (let me know if we should not set the notification channel). A test has been added to check these assignments.

The /api/secure/user/<id>/verify_sms POST endpoint now sets isPhoneNumberVerified = true and notificationChannel = "sms" upon receiving an "approved" phone verification status.

* Tests for the chain of API calls to verify a user's phone number.
*/
@Test
public void canSimulatePhoneVerificationFlow() {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this test really belongs here. This test class was intended to model how a third party API user interacts with otp-middleware. And an API user (eventually) won't be able to create an OtpUser that can register a phone number for SMS notifications.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I moved and changed the test in 44864ac.

Copy link
Contributor

@landonreed landonreed left a comment

Choose a reason for hiding this comment

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

Looks good. Just a couple of comments (location of test and automatically setting notification channel).

@codecov-io
Copy link

codecov-io commented Oct 8, 2020

Codecov Report

Merging #83 into dev will increase coverage by 5.76%.
The diff coverage is 51.85%.

Impacted file tree graph

@@             Coverage Diff              @@
##                dev      #83      +/-   ##
============================================
+ Coverage     38.74%   44.50%   +5.76%     
- Complexity      264      381     +117     
============================================
  Files            81       83       +2     
  Lines          2261     2775     +514     
  Branches        258      344      +86     
============================================
+ Hits            876     1235     +359     
- Misses         1301     1419     +118     
- Partials         84      121      +37     
Impacted Files Coverage Δ Complexity Δ
...org/opentripplanner/middleware/models/OtpUser.java 45.45% <ø> (+13.63%) 6.00 <0.00> (+2.00)
.../middleware/controllers/api/OtpUserController.java 45.45% <51.85%> (+5.45%) 6.00 <2.00> (+3.00)
...eware/controllers/api/MonitoredTripController.java 13.79% <0.00%> (-14.78%) 2.00% <0.00%> (ø%)
...rg/opentripplanner/middleware/utils/HttpUtils.java 50.00% <0.00%> (-7.15%) 20.00% <0.00%> (+10.00%) ⬇️
...tripplanner/middleware/otp/response/Itinerary.java 63.15% <0.00%> (-5.60%) 7.00% <0.00%> (+2.00%) ⬇️
...dleware/controllers/api/TripHistoryController.java 43.02% <0.00%> (-5.47%) 5.00% <0.00%> (+2.00%) ⬇️
...nner/middleware/controllers/api/LogController.java 40.84% <0.00%> (-5.46%) 2.00% <0.00%> (ø%)
.../middleware/controllers/response/ResponseList.java 68.42% <0.00%> (ø) 2.00% <0.00%> (?%)
...ipplanner/middleware/otp/response/OtpResponse.java 100.00% <0.00%> (ø) 2.00% <0.00%> (?%)
...a/org/opentripplanner/middleware/models/Model.java 40.90% <0.00%> (+0.90%) 4.00% <0.00%> (+2.00%)
... and 19 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6971187...6088b31. Read the comment docs.

.withDescription("Request an SMS verification to be sent to an OtpUser's phone number.")
.withPathParam().withName(ID_PARAM).withDescription("The id of the OtpUser.").and()
.withPathParam().withName(ID_PARAM).withRequired(true).withDescription("The id of the OtpUser.").and()
.withPathParam().withName(PHONE_PARAM).withRequired(true).withDescription("The phone number to validate, in E.164 format.").and()
Copy link
Contributor

@landonreed landonreed Oct 8, 2020

Choose a reason for hiding this comment

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

While precise, this isn't super helpful for most people. It would be good to add an example to this description (e.g., +15555551234).

Copy link
Contributor

Choose a reason for hiding this comment

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

This item is unresolved.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed. in e1e2cd2

Copy link
Contributor

@landonreed landonreed Oct 15, 2020

Choose a reason for hiding this comment

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

Sorry, I didn't mean to remove that it should be E.164 (which is nice because it is precise), just that we should add the example (for folks who don't immediately know what that means). To further clarify: we should be picky about the format used for this phone number field. If it doesn't match e.164, we should reject the request.

It looks like you have added a configurable regex for making this format flexible. I disagree with this change. We should just use a hard-coded regex and enforce a single format in requests.

Verification verification = NotificationUtils.sendVerificationText(otpUser.phoneNumber);

// Update OtpUser before submitting SMS request.
otpUser.phoneNumber = phoneNumber;
Copy link
Contributor

Choose a reason for hiding this comment

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

This approach overwrites the existing phone number before it is verified. If we do things this way, it will be impossible to send off alerts to the phone until it is verified. And if the user decides they actually don't want to verify after all and keep their old number, we will have overwritten it and they would have to go back in and reconfirm their existing phone number.

The temporary phone number should be stored in a temporary field until it is verified.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

See the Revert Number button in opentripplanner/otp-react-redux#224 for part of this concern.

Copy link
Contributor

Choose a reason for hiding this comment

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

I disagree with the approach of having a revert option due to some of the concerns shared above. Additionally, it is more code to maintain than keeping an existing phone number intact until verification and requiring the user to reverify an original number if they want to change it back.

// If the check is successful, update the OtpUser
// (set isPhoneNumberVerified and notificationChannel).
// TODO: Figure out adding a test for this update to the OtpUser record.
otpUser.isPhoneNumberVerified = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

Only at this point should the otpUser.phoneNumber be updated.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@landonreed and @evansiroky please agree on the above comment. 5621a13 does per above, d887661 does not.

Copy link
Contributor

Choose a reason for hiding this comment

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

Using isPhoneNumberVerified is how we originally designed things and in my opinion it works just fine. If there needs to be further discussion or an alternative approach, that should be handled outside of this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

I still disagree for reasons mentioned in company chat, but don't care enough to block progress.

Copy link
Contributor

@landonreed landonreed left a comment

Choose a reason for hiding this comment

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

Thanks for the changes, @binh-dam-ibigroup. I think the only thing left is to enforce E.164 format in requests. I'm not sure if something I said caused you to deviate from how you had originally designed things. If so, I apologize -- I think your instincts were correct!

Copy link
Contributor

@evansiroky evansiroky left a comment

Choose a reason for hiding this comment

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

Contingent on #83 (comment) and @landonreed's approval following E.164 regex hardcoding check.

Still disagree about overwritten a confirmed number with an unconfirmed one, but don't care enough to block progress.

@evansiroky evansiroky removed their assignment Oct 15, 2020
@ParameterizedTest
@MethodSource("createBadPhoneNumbers")
public void invalidNumbersShouldProduceBadRequest(Map.Entry<String, Integer> testCase) {
assumeTrue(testsShouldRun());
Copy link
Contributor

@landonreed landonreed Oct 21, 2020

Choose a reason for hiding this comment

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

I feel like there is a lot of churn happening on this auth disabled stuff, but I'm pretty sure in some PR we started to use the pattern of not checking DISABLE_AUTH=false but rather setting it with Auth0Connection#setAuthDisabled and reverting the value to getDefaultAuthDisabled in tearDown. Please follow that pattern here. Also, does e2e actually need to be enabled for these tests to work?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point. e2e is not required.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Updated in 8ec525a.

Copy link
Contributor

@landonreed landonreed left a comment

Choose a reason for hiding this comment

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

Just a couple of comments that could be addressed, but otherwise looks great.

@binh-dam-ibigroup binh-dam-ibigroup merged commit ee8c6d7 into dev Oct 28, 2020
@binh-dam-ibigroup binh-dam-ibigroup deleted the change-phone-persisting branch October 28, 2020 21:01
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.

Do not require persisting user in order to verify phone number
5 participants