-
Notifications
You must be signed in to change notification settings - Fork 904
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
Create handleRecaptchaFlow helper method #7666
Conversation
🦋 Changeset detectedLatest commit: edc0f50 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Size Report 1Affected Products
Test Logs |
Size Analysis Report 1Affected Products
Test Logs |
actionName: RecaptchaActionName, | ||
actionMethod: ActionMethod<TRequest, TResponse> | ||
): Promise<TResponse> { | ||
if (authInstance._getRecaptchaConfig()?.emailPasswordEnabled) { |
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.
Can we also include "provider" name or enum as a parameter? Based on that, we will know whether to check emailPasswordEnabled or a different provider.
Ok to handle this the next time we add a provider too. Please add a TODO in that case.
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.
Yeah, as an internal method, I prefer add the parameter only when needed so the context is more clear.
packages/auth/src/platform_browser/recaptcha/recaptcha_enterprise_verifier.ts
Outdated
Show resolved
Hide resolved
request: TRequest | ||
) => Promise<TResponse>; | ||
|
||
export async function handleRecaptchaFlow<TRequest, TResponse>( |
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.
can we add some tests for this method? I understand that usages of this methods in the various flows are being tested.. would be good to test this too.
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.
@renkelvin can you update the description that all rCE protected flows were manually verified with the demo app?
I am ok with moving the new unit tests to a different PR to debug them.
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.
Yeah, done.
authInstance, | ||
request, | ||
actionName, | ||
actionName === RecaptchaActionName.GET_OOB_CODE |
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.
Does this mean that for oobCodeFlows, we do not call the request field name as "captchaResp: token"?
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.
Correct, this is due to backend legacy issues.
} | ||
}); | ||
} | ||
return handleRecaptchaFlow( |
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.
Instead of calling signInWithCredential in packages/auth/src/core/strategies/email_and_password.ts, can we instead duplicate a bit of code and do something like:
export function signInWithEmailAndPassword(
auth: Auth,
email: string,
password: string
): Promise<UserCredential> {
const request: SignInWithPasswordRequest = {
returnSecureToken: true,
email: this._email,
password: this._password,
clientType: RecaptchaClientType.WEB
};
const response = handleRecaptchaFlow(auth, request, action, signInWithPassword)
.catch(error => {
if (error.code === `auth/${AuthErrorCode.MFA_REQUIRED}`) {
throw MultiFactorError._fromErrorAndOperation(
auth,
error,
operationType,
user
);
} else if (
error.code === `auth/${AuthErrorCode.PASSWORD_DOES_NOT_MEET_REQUIREMENTS}`
) {
void recachePasswordPolicy(auth);
} else {
throw error;
}
})
;
const userCredential = await UserCredentialImpl._fromIdTokenResponse(
auth,
OperationType.SIGN_IN,
response
);
await auth._updateCurrentUser(userCredential.user);
This will make the email login flow more consistent with the other flows in strategies/email_and_password.ts and we don't have to import any recaptcha enterprise methods here (enabling tree shaking out the JS script)
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.
Adding the comment here, but it is for the implementation in packages/auth/src/core/strategies/email_and_password.ts
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.
But doing this will not perform recaptcha enterprise wrapping if the developer is calling reauthenticateWithCredential or signInWithCredential directly... hmm.
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.
Yeah, I actually tried similar things when implementing the recapthca flow originally. I agree this part needs some refactors.
4774ddb
to
6b934c9
Compare
All flows manually verified in the demo app. Gonna add the unit tests in a separate PR.