Fix manual input token

[jacogr]

No description provided.

[derhuerst]

Can be simplified to this:

/([a-z0-9]{4}(-)?){4}/i

[derhuerst]

Also, I can't reproduce why -? -> (-)?.

/([a-z0-9]{4}-?){4}/i.test('2M28-4gXT-X2qW-bAa') // false
/([a-z0-9]{4}-?){4}/i.test('2M28-4gXT-X2qW-bAaS') // true

[derhuerst]

trimming the input might be worth, as users often copy & paste adjacent spaces.

[jacogr]

I can read and understand it as-is so the bug we introduced jumped out immediately. Since I can see no benefit in crunching apart from making me straining my brain & eyes, I'm not going to crush it.

[ngotchac]

Shouldn't it be at least /^[a-zA-Z0-9]{4}(-)?[a-zA-Z0-9]{4}(-)?[a-zA-Z0-9]{4}(-)?[a-zA-Z0-9]{4}$/

[ngotchac]

1232M28-4gXT-X2qW-bAaz is still valid

[jacogr]

The whole approach of having optional -'s is anyway questionable as logged. The output from parity ui new-token has the dashes, that is what we verify. If users copy from authcodes and play techy, they should know to add the -'s

[derhuerst]

@jacogr Not sure if you're responding to @ngotchac. afaict @ngotchac wants to add ^ and $ to the regex. His point is that the token may have invalid characters and still be valid right now.

[ngotchac]

The thing is that the token input but the user gets modified anyway via token.replace(/[^a-zA-Z0-9]/g, ''). IMO, the check should be whether the transformed token is valid or not (ie. being 16 chars long). That's how it's stored in localstorage too.

[jacogr]

We added the optional -'s due to an issue logged. My point is that issue is invalid since if you copy from authcodes, you should expect things to not work as you expected. We never direct any users there neither do we direct them to copy from storage. The ^ & $ is valid though, updated.

[coveralls]

Coverage increased (+0.03%) to 85.756% when pulling 5859b8d on jg-fix-manual-token into be75cbf on master.

[coveralls]

Coverage increased (+0.04%) to 85.765% when pulling 5859b8d on jg-fix-manual-token into be75cbf on master.