Hello. Just a little note to alert you to a couple of small tweaks we put out to the OAuth authorization screens today, which clears up the denial flow and improves the user experience for OS native applications.
We've fixed a confusing aspect of the denial flow in the Authorize and Authenticate interfaces. Previously, Deny (or Cancel) required a user to be signed in (it was used to invalidate any existing tokens the user had for the application.) This was especially annoying if the user wasn't signed in, as clicking Cancel would return an authentication error rather than just returning the user to whence they came. We've made a small change, which provides a good opportunity to lay out afresh how this part of the flow works, such that you can consider it your application design.
• In the tweaked flow, clicking Cancel when authorizing Web and Out-of-Band applications no-longer requires a user to authenticate, and takes them straight to the cancellation screen, which if they are logged in will confirm the application's current authorization state, and link back to the app to close the loop.
• Clicking Cancel when authorizing a native OS application (e.g. one with a non-HTTP(S) URL oauth_callback, such as twitterrific://) will now directly link the user back to the application via the custom-protocol callback.
• Since clicking Cancel in native apps will redirect a user directly, the “Cancel, and return to Application” link that was inserted below application descriptions has been removed. The conventional Cancel button will now do what the user expects. Removal of this link unclutters the layout, and the application description takes up less space in the smartphone version of the interface.
• Users can no-longer invalidate an access token through the authorize flow, which was never really a clear consequence of the interface. We instead direct users to their Application Settings page to revoke application access. If you have a place in your application prompting a user to revoke access to your application for any reason, please direct them there.
Hopefully you'll find this a useful adjustment, and please let me know if you run into any difficulties.
Ben.
Replies
As you mentioned that "can no-longer invalidate an access token through the authorize flow", I have a little bit confusion. Please clarify.
While accessing tweets using oAuth, if I give all incorrect values for consumer key, consumer secret key, access token and access token secret, still I am able to get tweets from users. But this thing is not possible when I try to post any comment to the twitter. Please verify is this the expected behavior when I was accessing tweets using wrong credentials.?
This is expected on v1 methods that support, but do not require authentication. If you provide invalid creds and the request can still be considered as an unauthenticated request (and the IPs quota isn't exhausted), we'll serve you the content anyway. statuses/update requires a user context and auth, so it doesn't work this way.
Thank you very much Taylor for the reply. As you guys have updated for v1.1 -
"In version 1.1, we will require every request to the API to be authenticated. For developers who are already using OAuth when making API requests, all of your authentication tokens will transition seamlessly from v1.0 to v1.1. If your application is currently using the Twitter API without using OAuth, you will need to update your application before March 2013."
->So is this expected as you mentioned as its does not require oAuth to access public tweets forever or till March?
->If the v1 methods that supports authentication and when it will change to v1.1 what are the things I need to change in my application to access public tweets?
OAuth will be required for all v1.1 endpoints. Once March 2013 comes and v1 is retired, you'll need to use OAuth for all requests, including requests for so-called public data.
What you'll need to change in your code will depend on what kind of code you've written and what libraries you're leveraging.
My application - Dalmatracker - stopped generating tweets from my website sometime on or after 10th Oct - uses cLibOAuth.asp. Has worked error free for years! - no site updates for months!!
How can I test/trace?
Regards
Paul Richards
You're probably effected by the so-called unversionedpocalypse -- you'll want to review your code and the URLs you use for API access as they are probably out of date.
See
We used https://github.com/jmathai/twitter-async as a connection library but since the 10th it's been broken. Despite changing all the urls we now have a broken app.
We aren't alone - the WP community is experiencing similar issues too and well, it isn't good as we now have to find a new library and change all sorts of dependencies.
Sure, things change we get that, but it kind of dampens one's enthusiasm to build anything else that use twitter in the way that we did.
Does anyone know anybody who's managed to get this library working?
Reworking a hatful of projects that use this library just isn't really an option.
Do you know the specific aspects of the library that aren't working?
OAuth is a multi-step process, at which step is it malfunctioning after you've updated the paths?
We had the same issue. Just update the URL that you use to talk to Twitter. The rest of the code should work fine.
You can find the new url on the same page whre your oAuth codes are locate d(it is near the top).
I believe if you use https://api.twitter.com/1.1/statuses/update.json in place of https://twitter.com/statuses/update.xml you will have success.