Can we change the wording on the PIN page of the desktop workflow?
Currently it is worded as follows:
You've successfully granted access to <ApplicationName>!
Enter the following PIN when prompted by <ApplicationName>
Obviously a desktop application has no idea that this flow actually
completed, and hence has no way to "prompt" the user to do anything. A
user could sit there for awhile waiting for a prompt.
I think it would be more clear if it was worded something along the
lines of:
You're almost done pairing <ApplicationName> with your Twitter account!
Simply return to <ApplicationName> and enter the following PIN to
complete the process.
Josh
Matt Sanford wrote:
Hello,
One of the things we've been saying about OAuth all along is that
we'll be improving the desktop application experience. Well, the time
is here for the first re-visit. As part of out changes for OAuth
version 1.0a [1] I have been looking at how this is going to work and
there is going to need to be a change that will not be backward
compatible. Some of this is already coded and waiting to go, and some
of it is in-progress. I expect we will deploy this the end of next
week or the beginning of the following one in order to allow you to
have a minimum of 7 days to make changes. These only effect desktop
applications so the majority of OAuth applications are not affected.
Here are the expected changes:
1. If your application is registered as a desktop application
callbacks will not be supported.
*Workaround*: Visit your application details page to change the
application type and provide a default callback URL.
*Details:* Dynamic callbacks are currently disabled for all
applications. With changes for 1.0a [1] will re-enable dynamic
callback support but applications registered as 'desktop' will not
support this. When requesting a request token the you will get an
error saying that callbacks are not supported in desktop applications.
This is to prevent stealing of tokens created with a PIN (see #2) by
webapps re-using the freely available desktop consumer key and secret.
2. If your application is registered as a desktop application there
will be a PIN the user must enter in your application
* Details*: In the current code desktop applications end in a
dead-end page. This new flow will give the user a PIN that they enter
in the application and that must be provided to swap a request token
for an access token. This will help secure tokens for desktop
applications since the security of the consumer key and secret cannot
be relied upon.
*Feedback: *We are planning to make this a required step but I am
open to discussion if anyone feels there is a compelling case for
desktop applications without a PIN. Email me directly with feedback.
3. If your application is registered as a desktop application you will
not be able to use the 'Sign in with Twitter' functionality.
*Details:* 'Sign in with Twitter' requires a callback URL which
will not be allowed per #1 above.
We're working to make sure we provide OAuth
interfaces wherever possible. Desktop applications was a definite
problem that needed some fixing. Close behind that is mobile web which
is currently being looked at by a group reviewing all of
m.twitter.com. If you have any objections to the changes above, or
some reason that you don't think it will work, please feel free to
email me directly.
Thanks;
– Matt Sanford / @mzsanford
Twitter Dev
[1] - OAuth spec 1.0a addresses problems with oauth_callback and
should be finalized very soon. More info
at http://groups.google.com/group/oauth/browse_frm/thread/b0345ad5b5466587
