Split Arkose::UserVerificationService into two services
This MR is the second of a multi-MR change to integrate Arkose Labs to the registration flow.
- Display Arkose Labs challenge in the registration form (instead of reCAPTCHA)
- Split
Arkose::UserVerificationService
intoArkose::TokenVerificationService
andArkose::RecordUserDataService
👈🏼 👈🏼 👈🏼 YOU ARE HERE - Verify Arkose Labs session token before registration and record Arkose Labs user data after registration
What does this MR do and why?
Split Arkose::UserVerificationService
into two services as follows:
-
Arkose::TokenVerificationService
- responsible for sending a request to Arkose Labs Verify API endpoint to perform verification of the session token passed from the frontend -
Arkose::RecordUserDataService
- responsible for persisting the user's data from Arkose Labs into the database. Currently, data persisted arearkose_session
(id),arkose_risk_band
,arkose_global_score
,arkose_custom_score
.
Functionally, there is one minor difference between the resulting two services and Arkose::UserVerificationService
. Previously, Arkose::UserVerificationService
prevents the user from logging in when they are not deemed low_risk
:
def execute
...
response.allowlisted? || (response.challenge_solved? && response.low_risk?)
end
Now Arkose::TokenVerificationService
just returns low_risk?
value as part of the ServiceResponse.payload
and delegates the decision whether to prevent the user from logging in to SessionsController
:
# ee/app/services/arkose/token_verification_service.rb
def execute
if response.allowlisted? || response.challenge_solved?
ServiceResponse.success(payload: { low_risk: response.allowlisted? || response.low_risk? })
else
ServiceResponse.error(message: 'Captcha was not solved')
end
end
# ee/app/controllers/ee/sessions_controller.rb
def verify_arkose_token(user)
result = Arkose::TokenVerificationService.new(session_token: params[:arkose_labs_token], user: user).execute
if result.success? && result.payload[:low_risk]
# allow log in
else
# prevent log in
end
end
This change is warranted since for registration flow we will allow the user to register regardless of their risk_score
.
Why?
This refactor is needed so we can verify a session token and persist user data in two separate steps during registration. TokenVerificationService
(step 1) will be executed before a user is created to ensure the CAPTCHA has been solved while RecordUserDataService
(step 2) will be executed after the user is created.
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.