- **status**: in-progress --> review
- **Comment**:
Closed #759, #760, #761.
`{allura,sftheme}:ib/7868`
**QA:**
Enable phone verification and config Nexmo in `production.ini`:
~~~~~
project.verify_phone = true
phone.method = nexmo
phone.api_key = XXX
phone.api_secret = XXX
~~~~~
You can register Nexmo account [here](https://dashboard.nexmo.com/register). By
default it's working in test mode, so only phone number used to register
account can be used for verification (you can whitelist more numbers for
testing in account settings). You'll also get 2€ credit for testing.
UI implemented using React.js as discussed [in this
thread](http://mail-archives.apache.org/mod_mbox/allura-dev/201505.mbox/%3CCAOH-Der%2BgiM_Pt2xbto58FEzoFHU9fz9JHx02Y02%2B5D6Hnv%3DVg%40mail.gmail.com%3E).
---
** [tickets:#7868] Phone verification system**
**Status:** review
**Milestone:** unreleased
**Labels:** sf-current sf-8 42cc
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Thu Apr 23, 2015 11:17 AM UTC
**Owner:** Igor Bondarenko
To control spam and other abuse, a phone verification system could be useful.
This would be optional for any Allura instance to use, of course.
Initially I'd like to see this on project registration. The
`ProjectRegistrationProvider` can provide methods to allow flexibility in
different deployments. A default implementation could be as follows. The
first time a user registers a project, they will be shown a followup screen
requesting a phone number for either SMS or voice verification. (If a user has
any existing non-deleted projects, this will be skipped and registration occurs
as normal). Verification occurs (see next paragraph). If verification
succeeds, record that on the user record so they won't have to verify again,
and add a user audit log too. Use a non-salted hash of the phone number, do
not ever store the full number. Then project registration actually occurs. If
verification fails, record an audit log also. Let the user try again.
For actual phone verification, we should set up a simple abstraction layer to
allow different verification services to be used. See the "spam.method" config
and `SpamFilter` classes as an example of that type of setup. Specific
implementations could include Twilio, Nexmo Verify, etc. These classes could
be used for different situations later too (e.g. two-factor login)
Site-specific messages will need to be included in this too. E.g. saying the
phone number will be used for verification only and will not be stored; or if
they are having problems how to contact support, etc. Simple text could be
handled with a config setting, more complex with a template override.
Don't need to apply this to project imports.
---
Sent from forge-allura.apache.org because [email protected] is subscribed
to https://forge-allura.apache.org/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.
