[TEST] Migrate to Prosopo Procaptcha

[Bullrich]

Fixes paritytech#337

PR to migrate rococo faucet from reCAPTCHA to Prosopo Procaptcha, which runs on the rococo test network.

Overview

When using Procaptcha, the flow of data in the faucet client app is as follows :

Frontend Flow

1. The user enters the page.
2. The user selects their network and how many tokens they require.
3. The user clicks the Procaptcha check box.
4. A Polkadot user_account is generated using fingerprinting as random entropy
5. The user_account and the faucet's site_key are passed to the Procaptcha Contract in rococo, and details of a random Captcha Provider are returned.
6. The rococo network is contacted, querying the Procaptcha Contract, and a Captcha Provider is returned
7. The website asks the Captcha Provider for a challenge, passing the site_key, user_account, block_number, and other data related to the Captcha Provider.
8. The Captcha Provider checks it was randomly selected by the Procaptcha Contract, by submitting the same read performed in step 5. using historical block data (e.g. queryAt(block_number))
9. Assuming step 8. is successful, the Captcha Provider returns a challenge
10. The user completes the challenge, and passes the solution to the Captcha Provider. If the solution is correct, the checkbox becomes ticked, a challenge payload is added to the form, and the form submission button becomes enabled
11. The user presses the form submission button and the form data + captcha payload are sent to the faucet backend

Additional Info

Page Reloads

We noticed that the reCAPTCHA implementation would ask the user for a new captcha on every page load. We have recreated this functionality using procaptcha by clearing any local storage on load of the CaptchaV2.svelte component. This prevents a locally stored Captcha Provider from being contacted on page reload, and passing the user_account due to their historical records stored on the Captcha Provider.

Max Verified Time

The maximum amount of time a captcha solution is valid for is 60s. This can be changed using the env variable PROCAPTCHA_MAX_VERIFIED_TIME, which takes a millisecond amount.

Backend Flow

We'll begin the backend flow from where the frontend flow left off.

1. The backend receives the form data from the frontend.
2. The backend takes the Procaptcha payload and passes it to a TypeScript package called @prosopo/server.
3. This package performs the following checks
   a. Check if the provider was actually chosen at block_number
   b. If a provider_url is passed with the payload, the Captcha Provider is contacted to verify the user. Otherwise, read the user_account score from the contract directly after checking the time since the last correct captcha is less than the maxVerifiedTime (60s, mentioned previously)
4. After 3a. or 3b. the user is either verified via a Captcha Provider or the Procaptcha Contract and will be permitted or denied their funds.

Testing

Client

Our client bundle continues to reach out to the rococo network for a random provider and the provider sends a real captcha. Solving this is clearly out of scope for UI tests so the provider is patched by injecting our mock provider (https://mockprovider.prosopo.io) into local storage. The mock provider always returns { "success": true } for the Alice account and the test site_key=5C4hrfjw9DjXZTzV3MwzrrAr9P1MJhSrvWGWqi1eSuyUpnhM, which is the all zero address.

E2E

As we are using a contract to return a provider, we implemented an additional contracts parachain in the E2E tests. This requires us to do the following:

1. deploy the Procaptcha Contract
2. register a Captcha Provider in the contract (We register our mock provider - https://mockprovider.prosopo.io)
3. store a Captcha Provider dataset in the contract
4. register an app (site_key) in the contract

Then when a random provider is selected, it is always the mock provider. Again, passing a user_account of Alice's address and the zero address for site_key returns { "success": true }. Obviously, the downside here is the time taken for transactions in 12s parachains in zombienet. We have tried to use the substrate-contracts-node, which has instant seal, alongside the zombienet configuration but didn't succeed.

We would appreciate any feedback on the approach so far!

---

Copied from paritytech#372

[cla-bot-2021-stg]

User @wilwade, please sign the CLA here.