-
Notifications
You must be signed in to change notification settings - Fork 248
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
feat(auth): Add TotpInfo
field to UserRecord
#558
Conversation
3f3e0e3
to
3f140e0
Compare
TotpInfo
field to UserRecord
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.
LGTM with nits.
1be035a
to
8c41cc7
Compare
5ccce00
to
4c5e08f
Compare
DisplayName string | ||
EnrollmentTimestamp int64 | ||
FactorID string | ||
PhoneMultiFactorInfo *PhoneMultiFactorInfo |
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.
Is this a user-facing field? If yes, we need an API review for it, right?
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.
Yes
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.
So we cannot merge this until the API change is approved, right? Can we keep PhoneNumber for now and merge the rest?
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.
Working on the API proposal for this.
@@ -69,11 +69,20 @@ var testUser = &UserRecord{ | |||
MultiFactor: &MultiFactorSettings{ | |||
EnrolledFactors: []*MultiFactorInfo{ | |||
{ | |||
UID: "0aaded3f-5e73-461d-aef9-37b48e3769be", | |||
UID: "enrolledPhoneFactor", |
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.
nit: can we keep the previous UID which is more representative of what the UID looks like?
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 would prefer it this way since we can test UIDs with integration tests but for more clarity as we add unit tests this might be better. What do you think? We can revert back to the previous UID and add comments if you feel strongly about this.
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.
since we can test UIDs with integration tests but for more clarity as we add unit tests this might be better
I am not sure what the human-readable UID gives us that the other alphanumeric value does not. Can you elaborate?
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.
Like you said, human-readable. It is just easier to write unit test cases as we add more factors here. I guess it doesn't make a lot of difference to have alphanumeric strings for unit tests as such because these are generated by the backend in the actual flow.
Please rebase this to use the |
…se-admin-go into totp-user-record
…se-admin-go into totp-user-record
…se-admin-go into totp-user-record
Moving this to #573 as per offline sync with @lahirumaramba to base it off |
Adding a
TotpInfo
field toUserRecord
for Admin users to view a user's MFA configuration. TOTP enrollment for users is enabled via client SDKs only.Testing was done by manually enrolling a user on TOTP using curl and creating a test app to get the corresponding user's UserRecord configuration
Manual testing output: