You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Dave Brondsema <da...@brondsema.net> on 2015/04/06 17:23:12 UTC
[allura:tickets] #7868 Phone verification system
---
** [tickets:#7868] Phone verification system**
**Status:** open
**Milestone:** unreleased
**Labels:** sf-current
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Mon Apr 06, 2015 03:23 PM UTC
**Owner:** nobody
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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Dave Brondsema <da...@brondsema.net>.
- **status**: review --> closed
- **Comment**:
There are some additional tweaks/enhancements I'd like to see but I'll do those as followup tickets, this is good.
---
** [tickets:#7868] Phone verification system**
**Status:** closed
**Milestone:** unreleased
**Labels:** sf-current sf-8 42cc
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Wed May 27, 2015 11:58 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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Dave Brondsema <da...@brondsema.net>.
- **Reviewer**: Dave Brondsema
---
** [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:** Tue May 12, 2015 12:15 PM 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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Igor Bondarenko <je...@gmail.com>.
- **labels**: sf-current, sf-8 --> sf-current, sf-8, 42cc
- **status**: open --> in-progress
- **assigned_to**: Igor Bondarenko
---
** [tickets:#7868] Phone verification system**
**Status:** in-progress
**Milestone:** unreleased
**Labels:** sf-current sf-8 42cc
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Mon Apr 06, 2015 05:47 PM 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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Igor Bondarenko <je...@gmail.com>.
- **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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Dave Brondsema <da...@brondsema.net>.
- **labels**: sf-current --> sf-current, sf-8
---
** [tickets:#7868] Phone verification system**
**Status:** open
**Milestone:** unreleased
**Labels:** sf-current sf-8
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Mon Apr 06, 2015 03:23 PM UTC
**Owner:** nobody
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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Igor Bondarenko <je...@gmail.com>.
- **status**: in-progress --> review
- **Comment**:
Closed #776, #777. Force-pushed `allura:ib/7868`
Also, sf-related changes on `forge-classic:ib/7868`.
QA:
Make sure that when popup is shown it preserves all values on original form. One exception of this is sf-specific "terms" checkbox. It's fine, since form doesn't care about it and it's validated only by js before form submission.
Make sure it works with local registration provider. I ran out of money on my Nexmo test account and didn't get a chance to test registration end-to-end for local provider. Partial testing tells me it should work, though.
---
** [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 May 21, 2015 08:22 PM 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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Dave Brondsema <da...@brondsema.net>.
- **status**: review --> in-progress
- **Comment**:
Some feedback so far. I have some more testing yet to do too.
* add react.js to LICENSE and Allura/LICENSE and rat-excludes.txt
* in `phone-verification.js` the function definition syntax is not quite right for `isInputDisabled` & `isButtonDisabled`
* `NexmoPhoneService` docstring doesn't need the "to enable" section
* The phone number is being logged, we don't want that. Could log the hashed version though. Probably shouldn't log the api secret either
* I'm thinking it would be useful to include hashes in the user audit logs.
* And for the hash, can we "canonicalize" it so its easy to check for a match if needed? I'm thinking stripping any non-alphanumeric chars (like whitespace and punctuation).
* `phone_verified()` should return `True` if user already is an admin of a project, so existing developers aren't affected when this is enabled. (That could be implemented in a SourceForge-specific provider, but seems reasonable to include by default)
* I'd rather have phone validation kick in after someone tries to submit the form, not right at the beginning (it might discourage more people). Can the overlay appear as part of the form submit?
---
** [tickets:#7868] Phone verification system**
**Status:** in-progress
**Milestone:** unreleased
**Labels:** sf-current sf-8 42cc
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Thu May 21, 2015 05:22 PM 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 dev@allura.apache.org 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.
[allura:tickets] #7868 Phone verification system
Posted by Dave Brondsema <da...@brondsema.net>.
- **labels**: sf-current, sf-8, 42cc --> sf-8, 42cc
---
** [tickets:#7868] Phone verification system**
**Status:** closed
**Milestone:** unreleased
**Labels:** sf-8 42cc
**Created:** Mon Apr 06, 2015 03:23 PM UTC by Dave Brondsema
**Last Updated:** Thu May 28, 2015 08:12 PM 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 dev@allura.apache.org 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.