>> 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 http://groups.google.com/group/twitter-development-talk/browse_thread/thread/853c4b6b839568b7/da1999e3ec8383e7#da1999e3ec8383e7 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 buggy. 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- unfriendly. 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