-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
* Tests for the chain of API calls to verify a user's phone number. | ||
*/ | ||
@Test | ||
public void canSimulatePhoneVerificationFlow() { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/main/java/org/opentripplanner/middleware/controllers/api/OtpUserController.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opentripplanner/middleware/controllers/api/OtpUserController.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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).
…o not set the notification chan
Codecov Report
@@ 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 Continue to review full report at Codecov.
|
src/main/java/org/opentripplanner/middleware/controllers/api/OtpUserController.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opentripplanner/middleware/controllers/api/OtpUserController.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opentripplanner/middleware/controllers/api/OtpUserController.java
Outdated
Show resolved
Hide resolved
.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() |
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This item is unresolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. in e1e2cd2
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/main/java/org/opentripplanner/middleware/models/OtpUser.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opentripplanner/middleware/models/OtpUser.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opentripplanner/middleware/utils/NotificationUtils.java
Outdated
Show resolved
Hide resolved
src/main/java/org/opentripplanner/middleware/utils/NotificationUtils.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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!
src/test/java/org/opentripplanner/middleware/controllers/api/OtpUserControllerTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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.
src/main/java/org/opentripplanner/middleware/controllers/api/OtpUserController.java
Outdated
Show resolved
Hide resolved
@ParameterizedTest | ||
@MethodSource("createBadPhoneNumbers") | ||
public void invalidNumbersShouldProduceBadRequest(Map.Entry<String, Integer> testCase) { | ||
assumeTrue(testsShouldRun()); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in 8ec525a.
src/test/java/org/opentripplanner/middleware/controllers/api/OtpUserControllerTest.java
Outdated
Show resolved
Hide resolved
src/test/java/org/opentripplanner/middleware/controllers/api/OtpUserControllerTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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.
…ut valid phone number.
Checklist
dev
before they can be merged tomaster
)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 setsisPhoneNumberVerified = false
and. A test has been added to check these assignments.notificationChannel = "sms"
(let me know if we should not set the notification channel)The
/api/secure/user/<id>/verify_sms
POST endpoint now setsisPhoneNumberVerified = true
andupon receiving an "approved" phone verification status.notificationChannel = "sms"