>> 4. What could we improve around the materials for integrating OAuth
into your application?

The standard OAuth docs are pretty good, but some of the Twitter-
specific implementation isn't documented and I've implemented code
based on current Twitter OAuth behavior, but this isn't a good way to
develop code.

Can you please provide documentation to address the question in

The question was: How to detect the "denied" condition on the Twitter
OAuth page (and is Twitter guaranteed to keep the current
implementation where the redirect app url has the word "denied" in it)

The OAuth page for mobile is extremely user-unfriendly and it is also
Here are some of the bugs that hurt OAuth adoption among developers
(and will hurt users who use mobile twitter apps with OAuth)

#1050 is a trivial bug fix - (The "Allow" button is in bold, but the
page defaults to "Deny")
#1045 is an even more trivial bug fix - (The "Signup" link redirects
to the "Login" page )
#395 addresses the larger issue of the OAuth page being mobile-

On Oct 12, 10:01 am, Ryan Sarver <rsar...@twitter.com> wrote:
> Hey everyone,
> I wanted to email the list to start gathering some feedback on how we
> can improve the OAuth workflow. As we have discussed in the past,
> Basic Auth is going to be deprecated at some point in the future for
> OAuth and we want to make sure we improve the experience to meet
> everyone's needs. I am interested in capturing feedback for both the
> web and desktop workflows.
> 1. What can be improved about the web workflow?
> 2. What can be improved about the desktop workflow?
> 3. What other models of distributed auth do you think we could learn
> from and what specifically about them?
> 4. What could we improve around the materials for integrating OAuth
> into your application?
> We really appreciate your feedback.
> Best, Ryan

Reply via email to