Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

sms verification modal #3336

Merged
merged 52 commits into from
Nov 17, 2016
Merged

sms verification modal #3336

merged 52 commits into from
Nov 17, 2016

Conversation

derhuerst
Copy link
Contributor

@derhuerst derhuerst commented Nov 10, 2016

This PR adds the ability for users to prove for a single account that they control an associated phone number. An account can only be verified once, just like a phone number can be used once.

Check out the diagram on how it works, over at the sms-verification repo. The server code is deployed at sms-verification.parity.io.

Note that this PR should not get merged before TJ provides a legal text, as we process potentially sensitive user data. Also, I need to do a few minor cleanups. The legal text is in place.

Edit: In 4931381, this PR also adds a maxConfirmations property to TxHash.

@derhuerst derhuerst added A3-inprogress ⏳ Pull request is in progress. No review needed at this stage. M6-ui labels Nov 10, 2016
@derhuerst
Copy link
Contributor Author

I'm not happy that, right now, a significant part of the logic happens in the React components of the modal dialog. If i close it, reload the page, or something fails/crashes, the process will get aborted. This may, in the worst case, lead to the user not being able to request an SMS.

setNumber, setConsentGiven, setCode
} = this.props.store;

if (phase === 4) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why we are not using a switch or else if here? (As it stands, single blocks should probably be on seperate lines, unless it follows the chain with an else if)

import styles from './sendConfirmation.css';

// TODO: move this to a better place
const nullable = (type) => PropTypes.oneOfType([ PropTypes.oneOf([ null ]), type ]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably put this in util - that way everybody can benefit. (And will clean up the same TODO comments everywhere)

import styles from './sendRequest.css';

// TODO: move this to a better place
const nullable = (type) => PropTypes.oneOfType([ PropTypes.oneOf([ null ]), type ]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per above util comment.

const { step, tx } = this.props;

if (step === POSTING_REQUEST) {
return (<p>A verification request will be sent to the contract. Please authorize this using the Parity Signer.</p>);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

()'s here would make sense if it was split into new lines for readability (see the bulk of the codebase), on a single line they are not needed.

return (<p>A verification request will be sent to the contract. Please authorize this using the Parity Signer.</p>);
}

if (step === POSTED_REQUEST) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

switch?

// You should have received a copy of the GNU General Public License
// along with Parity. If not, see <http://www.gnu.org/licenses/>.

const checkIfRequested = (contract, account) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would probably make more sense in js/contracts like all the other contract interfaces are wrapped.

// You should have received a copy of the GNU General Public License
// along with Parity. If not, see <http://www.gnu.org/licenses/>.

const checkIfTxFailed = (api, tx, gasSent) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per above - instead of single-file-functions, bundle them up and move to contracts so it is accessible.

// You should have received a copy of the GNU General Public License
// along with Parity. If not, see <http://www.gnu.org/licenses/>.

const checkIfVerified = (contract, account) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per above - single file functions. Rather follow the structure used/implemented elsewhere for the sake of consistency and discoverability.

import checkIfRequested from './check-if-requested';
import checkIfTxFailed from './check-if-tx-failed';
import waitForConfirmations from './wait-for-confirmations';
import postToVerificationServer from './post-to-verification-server';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Single file functions + contract discovery inside js/contracts as prompted.

return false;
}

if (this.step === GATHERED_DATA) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not using a switch for consistency? Also split block or use else-if for follow-on blocks - readability.

@action setNumber = (number) => {
this.number = number;
}
@action setConsentGiven = (consentGiven) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blank lines between functions.

this.code = code;
}

constructor (api, account) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

constructor first, then @actions, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about @observables and @computeds? The reason I put it below is that they read kind of like an interface description.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following from what we've done in the React classes, I always put the variables first (@observable), then the initialisation (constructor) then the actual @computed values (functions) then the actual @action (interact) & then the internals.

Valid question, suggestions welcome.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ngotchac Your views?

});

Promise.all([ fee, isVerified, hasRequested ])
.then(() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indent. Consider .all on same level. (As it stands there is stylign inconsistency with the Promise chain just above this one.)

.then((txHash) => {
this.requestTx = txHash;
return checkIfTxFailed(api, txHash, options.gas)
.then((hasFailed) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indent .then (as per the promise it is actually in)

if (hasFailed) {
throw new Error('Transaction failed, all gas used up.');
}
this.step = POSTED_REQUEST;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

block around if() {}

.then((txHash) => {
this.confirmationTx = txHash;
return checkIfTxFailed(api, txHash, options.gas)
.then((hasFailed) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent.

}

return (
<div className={ styles.confirm }>
<LinearProgress
className={ styles.progressbar }
min={ 0 } max={ 10 } value={ value }
min={ 0 } max={ maxConfirmations } value={ value }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

attribute per line (inconsistency here, I know not introduced here, but since we are fixing it, readability counts.)

@jacogr jacogr added A5-grumble 🔥 Pull request has minor issues that must be addressed before merging. and removed A0-pleasereview 🤓 Pull request needs code review. labels Nov 16, 2016
@GitCop
Copy link

GitCop commented Nov 17, 2016

There were the following issues with your Pull Request

  • Commit: afdda48
    • Your commit message body contains a line that is longer than 72 characters

Guidelines are available at https://github.com/ethcore/parity


This message was auto-generated by https://gitcop.com

@jacogr jacogr added A8-looksgood 🦄 Pull request is reviewed well. and removed A5-grumble 🔥 Pull request has minor issues that must be addressed before merging. labels Nov 17, 2016
@gavofyork gavofyork merged commit 25a7ff1 into master Nov 17, 2016
@gavofyork gavofyork deleted the sms-verification-modal branch November 17, 2016 15:42
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A8-looksgood 🦄 Pull request is reviewed well.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants