Issue 823 - twitter-api - Native OAuth Flow PIN Checksum

Project Home		Issues

Issue 823:	Native OAuth Flow PIN Checksum
	6 people starred this issue and may be notified of changes.	Back to list

Status:	Fixed
Owner:	m...@twitter.com
Closed:	Jul 15
Type-Enhancement
Priority-Low
Component-OAuth

Reported by josh.a.perry, Jul 09, 2009

Since the PIN number for completing the OAuth handshake is in a browser 
window separate from the application there is ample room for user error in 
cut-and-paste or memorization use cases.

Exacerbating the issue is the fact that a PIN can only be tried a single 
time against the API, if the user did make a mistake then they will be 
required to begin the entire OAuth flow again.

Request:

Could the last digit of the PIN be made into a mod 10 check digit? This is 
a very common method of verifying that a base-10 number was not corrupted. 
For detailed information on a mod 10 algorithm see http://en.wikipedia.org/wiki/Luhn_algorithm

This check digit would allow applications to tell if the PIN is valid 
without using the one and only API attempt to do so. Simply checking the 
number for a length of 6 is not very fool proof.

Comment 1 by m...@twitter.com, Jul 10, 2009

Code is completed and will probably be deployed next week.

Status: Accepted
Owner: m...@twitter.com
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low Component-OAuth

Comment 2 by m...@twitter.com, Jul 15, 2009

Check digit added to the end of the PIN.

Status: Fixed

Comment 3 by jfriedl, Jul 15, 2009

Can you PLEASE give some warning when you're going to break existing code like this,
announcing it on something with an RSS feed so developers have a chance to deploy new
binaries, and users have a chance to download and install them. Your API
documentation *still* cites a six-digit pin, and the API announcements mailing list
has no mention of this.

THIS API CHANGE IS NOT BACKWARD COMPATIBLE.  IT BREAKS EVERY APP THAT FOLLOWS THE
API. A 7-DIGIT PIN IS NOT SIX DIGITS.

Sigh. If you continue treat developers like this, they will abandon you.

Comment 4 by josh.a.perry, Jul 15, 2009

Sorry, When I made the request I assumed that the 6th digit would just be made a check-
digit which would have preserved compatability.

I'm ecstatic that the flow for OAuth in native applications is being so actively 
supported. And as that support is hashed out the old RFC adage comes to mind "Be strict 
in what you send, but generous in what you receive".

Comment 5 by severedcross, Jul 20, 2009

So are we using the Luhn algorithm for checking the digit? Also, what are apps
supposed to do with this? Do we only pass 6 digits and exclude the check digit, or
include the check digit when sending the PIN back to Twitter? A little more direction
would've been appreciated, and I have to agreee with jfriedl here.

Comment 6 by jasonmp85, Jul 22, 2009

It's pretty clear from the wiki page which is the check digit (the rightmost one is), and 
I'd assume that sending only the six other digits is the correct course of action.

It is astonishing how quickly a single user's request went from idea to coded to 
deployed. Did anyone stop and question whether or not this user's idea was a good 
one? "Copy-and-paste errors"? If you're worried about those, put the check bit in 
your memory, not in the API.

Double-click text: cmd+c -> cmd+v. Done, and no chance of error.

This is really astonishing. Backwards-incompatible changes should be pre-
announced, not casually mentioned in changelogs.

Comment 7 by severedcross, Jul 24, 2009

@jasonmp85: Actually, you do have to send all 7 digits--sending only the first 6
results in a 401 Unauthorized. Thankfully, my OAuth implementation didn't rely on the
PIN being only 6 digits (it would accept PINs of any length theoretically), so no
real harm was done. However, I agree with you on the rest of your points.