Create reusable Arkose::VerifyResponse class
Part of https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/28.
Background
In https://gitlab.com/groups/gitlab-org/modelops/anti-abuse/-/epics/3 we want to integrate Arkose captcha challenge into the registration flow (Arkose captcha challenge only happens during login currently).
Part of the Arkose captcha challenge flow is the backend verifying an Arkose token passed from the frontend. This happens in Arkose::UserVerificationService
. In addition to token verification, this service is also responsible for persisting user data returned by Arkose to the DB. This implementation is enough to make Arkose captcha challenge work during user login.
To integrate Arkose captcha challenge into the registration flow, we need to split Arkose::UserVerificationService
into two services:
- Service A: responsible for verifying Arkose token passed from the FE
- Service B: responsible for persisting the user data returned by Arkose to the DB
This separation is needed since during registration, a new user will not be created until the Arkose token is verified but we need a user to save the user data returned by Arkose and associate it with that user.
Proposed registration flow using two services as mentioned previously
- User fills up the registration form, solves Arkose captcha, and submit the form (this sends Arkose token to the BE)
-
TokenVerificationService
: BE verifies token by hitting Arkose Verify API endpoint (user is not created yet at this point) - If the token is not verified successfully send the user back to (1)
-
UserDataRecorderService
: If the token is verified successfully, create the new user then save Arkose user data
What does this MR do?
This MR is the first iteration of splitting Arkose::UserVerificationService
into two services. It extracts methods used both during token verification and user data recording into a separate class (Arkose::VerifyResponse
). This new class will be used by both services that we will eventually create.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.