-
Notifications
You must be signed in to change notification settings - Fork 202
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
supporting recaptcha verdict for auth blocking functions #1458
Conversation
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 few minor things, but looks great and thanks for your work on this! Also, please add an entry to the changelog documenting the changes. Will leave this in a commented state until we get the go-ahead from the API council.
src/common/providers/identity.ts
Outdated
}; | ||
} | ||
|
||
/** Helper to generate payload to GCIP from client request. |
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.
add newline after /**
src/common/providers/identity.ts
Outdated
*/ | ||
export function generateRequestPayload( | ||
authResponse?: BeforeCreateResponse | BeforeSignInResponse | ||
): any { |
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.
Do we know exactly the shape of the data GCIP expects? If we do then we could statically type the return value here instead of using any
, otherwise not really a huge deal.
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.
+1, let's avoid 'any' if possible. I guess BeforeSignInResponse is the type to use? (Or if we consolidate all fields into BlockingFunctionsResponse we could use that, in future)
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.
BeforeSignInResponse is the interface for blocking function returns for developers (e.g. developers can return displayName, emailVeried etc field when they implemented the blocking function). The requestPayload(responsePayload) here is (will be) a new different interface that follows GCIP backend proto. They are very similar but nested a bit differently. This is also the reason why the naming is kind of confusing, it is generated from the blocking function response as a request to GCIP backend.
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.
Added a new interface for this.
src/common/providers/identity.ts
Outdated
@@ -338,8 +339,13 @@ export interface AuthBlockingEvent extends AuthEventContext { | |||
data: AuthUserRecord; | |||
} | |||
|
|||
/** The base handler response type for beforeCreate and beforeSignIn blocking events*/ | |||
export interface BlockingFunctionResponse { | |||
recaptchaPassed?: boolean; |
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 all fields are optional in BeforeCreateResponse and BeforeSignInResponse, should we put them all here? I understand this will be a much larger refactor, so this change is very optional.
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.
Actually, given this is a public interface, I think we should keep it as you have it here. Maybe we can have an internal/hidden interface which consolidates all the fields, mainly as return type for generatePayloadRequest.
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.
The reason why separating this out is this new interface will be used in the beforeEmailSent trigger. And in the beforeEmailSent response, recaptchaPassed
is the only field we support.
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.
makes sense.. Since the fields are all optional, technically, we could use the same Response for beforeEmailSent trigger. But what you have is cleaner.
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.
Updates from API proposal - we are going to rename recaptchaPassed to recaptchaActionOverride and add this property to both BeforeCreateResponse and BeforeSignInResponse same as Pavithra suggested here.
src/common/providers/identity.ts
Outdated
*/ | ||
export function generateRequestPayload( | ||
authResponse?: BeforeCreateResponse | BeforeSignInResponse | ||
): any { |
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.
+1, let's avoid 'any' if possible. I guess BeforeSignInResponse is the type to use? (Or if we consolidate all fields into BlockingFunctionsResponse we could use that, in future)
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 making the changes!
@@ -762,4 +770,52 @@ describe("identity", () => { | |||
); | |||
}); | |||
}); | |||
|
|||
describe("generateRequestPayload", () => { |
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.
"generateResponsePayload"
src/common/providers/identity.ts
Outdated
@@ -338,8 +339,13 @@ export interface AuthBlockingEvent extends AuthEventContext { | |||
data: AuthUserRecord; | |||
} | |||
|
|||
/** The base handler response type for beforeCreate and beforeSignIn blocking events*/ | |||
export interface BlockingFunctionResponse { | |||
recaptchaPassed?: boolean; |
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.
makes sense.. Since the fields are all optional, technically, we could use the same Response for beforeEmailSent trigger. But what you have is cleaner.
src/common/providers/identity.ts
Outdated
[key: string]: any; | ||
} | ||
|
||
/** @internal */ |
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: add a comment on why this is used.
"Internal definition to include all the fields that can be sent as a response from the blocking function to the backend. This is added mainly to have a type definition for 'generateResponsePayload'".
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 besides one very minor nit
src/common/providers/identity.ts
Outdated
@@ -673,7 +678,8 @@ export function generateResponsePayload( | |||
return {}; | |||
} | |||
|
|||
const { recaptchaPassed, ...formattedAuthResponse } = authResponse; | |||
const { recaptchaActionOverride: recaptchaActionOverride, ...formattedAuthResponse } = |
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.
Am I missing something with the destructuring assignment for recaptchaActionOverride
, or can we just do const { recaptchaActionOverride, ...formatedAuthResponse } = authResponse;
instead?
src/common/providers/identity.ts
Outdated
/** | ||
* The reCACPTCHA action options. | ||
*/ | ||
export type RecatpchaActionOptions = "ALLOW" | "BLOCK"; |
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: "Recaptcha" typo. Also in the comment.
74e9148
to
398cfc0
Compare
Description
Adding recaptcha support for auth blocking function beforeCreate and beforeSignIn
Code sample
V2
V1