[WPB-9065] Stop supporting phone numbers in supported client API vers…

…ions (#4045)

* Deny registering a new user with a phone number

* Update user registration documentation

* Update the user activation documentation

* Disable user activation via a phone code

* Ignore the voice_call field in POST /activation/send

* stern-test: fail to get users by phone with error

* stern: prevent updating phone numbers, clean up some brig.

* brig: WIP clean up phone-related tests.

* brig: updated failing test.

* Migrate a test: POST /activate/send: invalid phone

* brig: change error label and msg for invalid phone errors

* Update SendActivationCode golden tests

* Make `PUT i/users/:uid/sso-id` not fail

* Fix `POST /activate/send - 403 prefix excluded`

* Fix more tests

* Remove more phone-related code

* Fix Stern calls to internal Brig API

* Drop phones from Brig.Code

* Remove brig phone modules

* Restore public API

* Revert brig phone middleware hack

* Remove all references to Twilio and Nexmo

* Fix test send-phone-code

* Fix test "post /register - 201 existing activation"

* Fix test for registering w/o email and password

* Revert "Ignore the voice_call field in POST /activation/send"

This reverts commit c5992c5.

* Revert changes to golden tests for NewUser type

This undoes the changes to the tests that expected a failure while
parsing. Instead, we rely on failing at the handler execution time.

* Remove phone and full identity constructor

* Fix Cassandra queries in Brig (no phone selection)

* Fix spar tests

* Remove phone prefix code

* Remove PhoneBudgetTimeout

* Remove BlacklistedPhone error

* Add CHANGELOG entries

* Fix last TODOs

* Drop "phone" from an identity error message

* Fix user identity and activation response unit and golden tests

* Remove unused golden test files

* Fix NewUser golden tests

* Stern: remove tests for removed endpoints

* brig-types golden test: use email instead of phone

* Drop the excluded_phones DB table

* Revert "Drop the excluded_phones DB table"

This reverts commit 6174f1b.

* Make new Ormolu happy

* Align with fisx'es changes

Remove some unused phone types

* Brig: fix dependency on wire-subsystems

* Hi CI

---------

Co-authored-by: Igor Ranieri <[email protected]>
Co-authored-by: Paolo Capriotti <[email protected]>

cabal.project

@@ -19,7 +19,6 @@ packages:
   , libs/metrics-core/
   , libs/metrics-wai/
   , libs/polysemy-wire-zoo/
-  , libs/ropes/
   , libs/schema-profunctor/
   , libs/sodium-crypto-sign/
   , libs/ssl-util/
@@ -136,8 +135,6 @@ package repair-handles
     ghc-options: -Werror
 package rex
     ghc-options: -Werror
-package ropes
-    ghc-options: -Werror
 package schema-profunctor
     ghc-options: -Werror
 package service-backfill

changelog.d/0-release-notes/remove-phone-support.md

@@ -0,0 +1,4 @@
+Phone registration and login is not supported anymore. All API endpoints dealing with phone numbers and phone activation codes now fail with a 400 error. Brig options related to phone number support have now been deleted, namely:
+ - `setTwilio`
+ - `setNexmo`
+ - `setAllowlistPhonePrefixes`.

changelog.d/1-api-changes/remove-internal-phone-endpoints.md

@@ -0,0 +1,10 @@
+Internal API endpoints related to phone numbers have been removed.
+
+In brig:
+- `iGetPhonePrefix`
+- `iDeletePhonePrefix`
+- `iPostPhonePrefix`.
+
+In stern:
+- `get-users-by-phone`
+- `put-phone`.

charts/brig/templates/configmap.yaml

@@ -253,8 +253,6 @@ data:
       {{- if .setExpiredUserCleanupTimeout }}
       setExpiredUserCleanupTimeout: {{ .setExpiredUserCleanupTimeout }}
       {{- end }}
-      setTwilio: /etc/wire/brig/secrets/twilio-credentials.yaml
-      setNexmo: /etc/wire/brig/secrets/nexmo-credentials.yaml
       setUserMaxConnections: {{ .setUserMaxConnections }}
       setCookieInsecure: {{ .setCookieInsecure }}
       setUserCookieRenewAge: {{ .setUserCookieRenewAge }}

charts/brig/templates/secret.yaml

@@ -20,8 +20,6 @@ data:
   awsKeyId: {{ .awsKeyId | b64enc | quote }}
   awsSecretKey: {{ .awsSecretKey | b64enc | quote }}
   {{- end }}
-  twilio-credentials.yaml: {{ .setTwilio | b64enc | quote }}
-  nexmo-credentials.yaml: {{ .setNexmo | b64enc | quote }}
   {{- if (not $.Values.config.useSES) }}
   smtp-password.txt: {{ .smtpPassword | b64enc | quote }}
   {{- end }}

deploy/dockerephemeral/federation-v0/brig.yaml

@@ -200,9 +200,6 @@ optSettings:
   # To only allow specific email address domains to register, uncomment and update the setting below
   # setAllowlistEmailDomains:
   #   - wire.com
-  # To only allow specific phone number prefixes to register uncomment and update the settings below
-  # setAllowlistPhonePrefixes:
-  #   - "+1555555"
   # needs to be kept in sync with services/nginz/integration-test/resources/oauth/ed25519_public.jwk
   setOAuthJwkKeyPair: /etc/wire/brig/conf/oauth-ed25519.jwk
   setOAuthAuthCodeExpirationTimeSecs: 3 # 3 secs

docs/src/developer/reference/user/activation.md

@@ -6,7 +6,8 @@ _Author: Artyom Kazak_
 
 ---
 
-A user is called _activated_ they have a verified identity -- e.g. a phone number that has been verified via a text message, or an email address that has been verified by sending an activation code to it.
+A user is called _activated_ when they have a verified identity -- an email
+address that has been verified by sending an activation code to it.
 
 A user that has been provisioned via single sign-on is always considered to be activated.
 
@@ -25,24 +26,31 @@ The only flow where it makes sense for non-activated users to exist is the [wire
 ### Requesting an activation code
 (RefActivationRequest)=
 
-During the [standard registration flow](RefRegistrationStandard), the user submits an email address or phone number by making a request to `POST /activate/send`. A six-digit activation code will be sent to that email address / phone number. Sample request and response:
+During the [standard registration flow](RefRegistrationStandard), the user
+submits an email address by making a request to `POST /activate/send`. A
+six-digit activation code will be sent to that email address. Sample request and
+response:
 
 ```
 POST /activate/send
 
 {
-    // Either 'email' or 'phone'
-    "phone": "+1234567890"
+    // the user's 'email' address
+    "email": "[email protected]"
 }
 ```
 
 ```
 200 OK
 ```
 
-The user can submit the activation code during registration to prove that they own the email address / phone number.
+The user can submit the activation code during registration to prove that they
+own the email address.
 
-The same `POST /activate/send` endpoint can be used to re-request an activation code. Please use this ability sparingly! To avoid unnecessary activation code requests, users should be warned that it might take up to a few minutes for an email or text message to arrive.
+The same `POST /activate/send` endpoint can be used to re-request an activation
+code. Please use this ability sparingly! To avoid unnecessary activation code
+requests, users should be warned that it might take up to a few minutes for an
+email to arrive.
 
 ### Activating an existing account
 (RefActivationSubmit)=
@@ -53,8 +61,8 @@ If the account [has not been activated during verification](RefRegistrationNoPre
 POST /activate
 
 {
-    // One of 'phone', 'email', or 'key'
-    "phone": "+1234567890",
+    // One of 'email', 'key'
+    "email": "[email protected]",
 
     // 6-digit activation code
     "code": "123456",
@@ -69,14 +77,16 @@ POST /activate
 200 OK
 
 {
-    "phone": "+1234567890",
+    "email": "[email protected]",
 
     // Whether it is the first successful activation for the user
     "first": true
 }
 ```
 
-If the email or phone has been verified already, `POST /activate` will return status code `204 No Content`. If the code is invalid, `POST /activate` will return status code `404 Not Found` with `"label": "invalid-code"`.
+If the email has been verified already, `POST /activate` will return status code
+`204 No Content`. If the code is invalid, `POST /activate` will return status
+code `404 Not Found` with `"label": "invalid-code"`.
 
 There is a maximum of 3 activation attempts per activation code. On the third failed attempt the code is invalidated and a new one must be requested.
 
@@ -112,7 +122,7 @@ GET /self
 }
 ```
 
-If the profile includes `"email"` or `"phone"`, the account is activated.
+If the profile includes `"email"`, the account is activated.
 
 ## Automating activation via email
 (RefActivationEmailHeaders)=
@@ -134,30 +144,27 @@ X-Zeta-Key: ...
 X-Zeta-Code: 123456
 ```
 
-## Phone/email whitelist
+## Email whitelist
 (RefActivationAllowlist)=
 
-The backend can be configured to only allow specific phone number prefixes and email address domains to register. The following options have to be set in `brig.yaml`:
+The backend can be configured to only allow specific email address domains to register. The following option has to be set in `brig.yaml`:
 
 ```yaml
 optSettings:
   setAllowlistEmailDomains:
     - wire.com
     - example.com
     - notagoodexample.com
-  setAllowlistPhonePrefixes:
-    - "+49"
-    - "+1555555"
 ```
 
 When those options are present, the backend will match every activation request against these lists.
 
-If an email address or phone number are rejected by the whitelist, `POST /activate/send` or `POST /register` will return `403 Forbidden`:
+If an email address is rejected by the whitelist, `POST /activate/send` or `POST /register` will return `403 Forbidden`:
 
 ```json
 {
     "code": 403,
     "label": "unauthorized",
-    "message": "Unauthorized e-mail address or phone number."
+    "message": "Unauthorized e-mail address"
 }
 ```

docs/src/developer/reference/user/registration.md

@@ -12,16 +12,17 @@ This page describes the "normal" user registration flow. Autoprovisioning is cov
 
 The vast majority of our API is only available to Wire users. Unless a user is autoprovisioned, they have to register an account by calling the `POST /register` endpoint.
 
-Most users also go through [activation](activation.md) -- sharing and verifying an email address and/or phone number with Wire. This can happen either before or after registration. [Certain functionality](RefActivationBenefits) is only available to activated users.
+Most users also go through [activation](activation.md) -- sharing and verifying
+an email address with Wire. This can happen either before or after registration.
+[Certain functionality](RefActivationBenefits) is only available to activated
+users.
 
 ## Standard registration flow
 (RefRegistrationStandard)=
 
-During the standard registration flow, the user first calls [`POST /activate/send`](RefActivationRequest) to pre-verify their email address or phone number. Phone numbers must be in [E.164][] format.
+During the standard registration flow, the user first calls [`POST /activate/send`](RefActivationRequest) to pre-verify their email address.
 
-[E.164]: https://en.wikipedia.org/wiki/E.164
-
-After receiving a six-digit activation code via email/text message, it can be submitted with the registration request via `POST /register`. If the code is correct, the account will be activated immediately. Here is a sample request and response:
+After receiving a six-digit activation code via email message, it can be submitted with the registration request via `POST /register`. If the code is correct, the account will be activated immediately. Here is a sample request and response:
 
 ```
 POST /register
@@ -30,13 +31,13 @@ POST /register
     // The name is mandatory
     "name": "Pink",
 
-    // 'email', 'phone', or both have to be provided
+    // 'email' has to be provided
     "email": "[email protected]",
 
     // The password is optional
     "password": "secret",
 
-    // 6-digit 'email_code' or 'phone_code'
+    // 6-digit 'email_code'
     "email_code": "123456"
 }
 ```
@@ -76,7 +77,9 @@ If the code is incorrect or if an incorrect code has been tried enough times, th
 
 _NOTE: This flow is currently not used by any clients. At least this was the state on 2020-05-28_
 
-It is also possible to call `POST /register` without verifying the email address or phone number, in which case the account will have to be activated later by calling [`POST /activate`](RefActivationSubmit). Sample API request and response:
+It is also possible to call `POST /register` without verifying the email
+address, in which case the account will have to be activated later by calling
+[`POST /activate`](RefActivationSubmit). Sample API request and response:
 
 ```
 POST /register
@@ -85,7 +88,7 @@ POST /register
     // The name is mandatory
     "name": "Pink",
 
-    // 'email', 'phone', or both have to be provided
+    // 'email'  has to be provided
     "email": "[email protected]",
 
     // The password is optional
@@ -109,13 +112,15 @@ Set-Cookie: zuid=...
 }
 ```
 
-A verification email will be sent to the email address (if provided), and a verification text message will be sent to the phone number (also, if provided).
+A verification email will be sent to the email address (if provided).
 
 ## Anonymous registration, aka "Wireless"
 (RefRegistrationWireless)=
 
 
-A user can be created without either email or phone number, in which case only `"name"` is required. The `"name"` does not have to be unique. This feature is used for [guest rooms](https://wire.com/en/features/encrypted-guest-rooms/).
+A user can be created without email, in which case only `"name"` is required.
+The `"name"` does not have to be unique. This feature is used for [guest
+rooms](https://wire.com/en/features/encrypted-guest-rooms/).
 
 An anonymous, non-activated account is only usable for a period of time specified in `brig.yaml` at `zauth.authSettings.sessionTokenTimeout`, which is set to 1 day for Wire production. (The access cookie returned by `/register` can not be refreshed, and an anonymous user can not use `/login` to get a new cookie.)
 
@@ -172,7 +177,7 @@ These end-points support 5 flows:
 
 We need an option to block 1, 2, 5 on-prem; 3, 4 should remain available (no block option).  There are also provisioning flows via SAML or SCIM, which are not critical. In short, this could refactored into:
 
- * Allow team members to register (via email/phone or SSO)
+ * Allow team members to register (via email or SSO)
  * Allow ephemeral users
 
 During registration, we can take advantage of [NewUserOrigin](https://github.com/wireapp/wire-server/blob/a89b9cd818997e7837e5d0938ecfd90cf8dd9e52/libs/wire-api/src/Wire/API/User.hs#L625); we're particularly interested in `NewUserOriginTeamUser` --> only `NewTeamMember` or `NewTeamMemberSSO` should be accepted. In case this is a `Nothing`, we need to check if the user expires, i.e., if the user has no identity (and thus `Ephemeral`).

docs/src/how-to/install/infrastructure-configuration.md

@@ -527,23 +527,6 @@ Additionally, you may wish to build, sign, and host your own docker
 images to have increased confidence in those images. We haved "signed
 container images" on our roadmap.
 
-## Sign up with a phone number (Sending SMS)
-
-**Provides**:
-
-- Registering accounts with a phone number
-
-**You need**:
-
-- a [Nexmo](https://www.nexmo.com/) account
-- a [Twilio](https://www.twilio.com/) account
-
-**How to configure**:
-
-See the `brig` chart for configuration.
-
-(rd-party-proxying)=
-
 ## 3rd-party proxying
 
 You need Giphy/Google/Spotify/Soundcloud API keys (if you want to