[twitter-dev] Twitter OAuth Authentication Fails

[Kevin Wallace]

I have three iPhone apps that use OAuth to communicate with Twitter.
They have been working well for several months but recently when
trying to set-up authentication and exchange the various OAuth tokens
using Safari on the iPhone, Safari brings up a page from Twitter that
says:

Something is technically wrong.
Thanks for noticing -- we're going to fix it up and have things back
to normal soon.

Normally authentication works and the page Twitter returns redirects
back to our application on the iPhone.  Again, this has all worked for
several months until very recently.  We just noticed the problem
ourselves today.  Here's an example authenticate URL that used to work
but now fails:

http://twitter.com/oauth/authenticate?oauth_token=r8ZW21dPbUteSOgfFJ0AZnHkIwg1GfvRn9HaNMB7q0&force_login=true

Does anyone out there know what's going wrong?  This has all worked
for hundreds of thousands of our customers for several months now and
nothing in our app has changed in two months.  Can anyone shed light
on this for me?  Thanks!

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en

[twitter-dev] Re: Changing the Content-Type header for OAuth token exchanges

[Kevin Wallace]

This change has broken Twitter support in our iPhone apps (Runmeter,
Walkmeter,  and Cyclemeter). (They're among the top 100 iPhone apps in
the App Store's Health and Fitness category.)  Our customers are
starting to write us because they cannot connect to Twitter using our
app which uses Sign In With Twitter and OAuth.  We would greatly
appreciate it if you would go back to text/plain, at least until we
can release versions of our app that will accept application/x-www-
form-urlencoded.  Otherwise our customers are screwed until then.

Kevin Wallace
Abvio LLC
Founder

On Mar 10, 1:13 pm, Marcel Molina  wrote:
> This change has been deployed. Let us know if things get wonky.
>
> On Mon, Mar 8, 2010 at 3:39 PM, Mark McBride  wrote:
> > All -
>
> > Per issue 1263 (http://code.google.com/p/twitter-api/issues/detail?id=1263)
> > (and the OAuth spec), we're looking to change the Content-Type header for
> > OAuth token exchanges to 'application/x-www-form-urlencoded'.  To date it
> > has been 'text/html'.  We want to ensure that this will not break existing
> > applications, so if you have any qualms please voice them here.
>
> >   ---Mark
>
> >http://twitter.com/mccv
>
> --
> Marcel Molina
> Twitter Platform Teamhttp://twitter.com/noradio

[twitter-dev] Re: DDoS Status Update

[dwight wallace]

Great job :) Hopefully you can crate a security environment to
preclude future attacks.

On Aug 7, 11:05 am, Ryan Sarver  wrote:
> I wanted to send everyone an update to let you know what has been happening,
> the known issues, some suggestions on how to resolve them and some idea of
> how to move forward.
>
> *Whats been happening*
> As you know all too well Twitter, among other services, has been getting hit
> pretty hard with a DDoS attack over the past 24+ hours. Yesterday we saw the
> attack come in a number of waves and from a number of different vectors
> increasing in intensity along the way. We were able to stabilize our own
> service for a bit, hence Biz's post saying all was
> well,
> but that didn't mean the attacks had ceased. In fact, at around 3am PST
> today the attacks intensified to almost 10x of what it was yesterday. In
> order for us to defend from the attack we have had to put a number of
> services in place and we know that some of you have gotten caught in the
> crossfire. Please know we are as frustrated as you are and wish there was
> more we could have communicated along the way.
>
> *Known Issues*
> * - HTTP 300 response codes* - One of the measures in thwarting the
> onslaught requires that all traffic respect HTTP 30x response codes. This
> will help us identify the good traffic from the bad.
> * - General throttling* - Try to throttle your services back as much as
> possible for you to continue operating. We are working on our end to better
> understand the logic used in throttling traffic on the edge of the network
> and will communicate what we can, but the best idea is to just throttle back
> as much as you can in the mean time.
> * - Streaming API* - as part of the edge throttling we know requests to the
> Streaming API with lists of keywords or uses are getting dropped because the
> request is too large. We are working to get this filter removed and will
> update the list when we know more.
> - *Unexpected HTTP response codes* - we know people are seeing a lot of
> other weirdness and we aren't exactly sure what to attribute the various
> issues to, but know that you aren't alone.
>
> As the attacks change our tactics for defense will likely need to change as
> well, so stay active on the list and let us know what problems you are
> seeing and we will do our best to help guide you along.
>
> *Moving forward *
> We will try to communicate as much as we can so you guys are up to speed as
> things change and progress. I personally apologize for not communicating
> more in the mean time but there hasn't been much guidance we have been able
> to give other than hold tight with us. We fully appreciate all the long
> hours you are putting in to keep your apps running and supporting your users
> and know we are frustrated with you. Continue to watch this list,
> status.twitter.com and @twitterapi for updates
>
> Thanks for your patience, Ryan
>
> PM, Platform Team
> @rsarver 

[twitter-dev] oAuth - Application Website

[Wallace]

I have gotten my oAuth based app to deploy (finally - its a long
story).  One problem I am seeing is that when I look at the url link
for my app, it is different from the url entered into on my app on the
oAuth_clients setting for "Application Website"  The entry is correct
in my application's settings but the link is going to the incorrect
place in the url link for my app.  Anyway to get this resolved?

Wally

[twitter-dev] Re: oAuth in the cloud

[Wallace]

Paul,

Thanks for the clarification.  I'm still learning so any suggestions
are appreciated.

Wally

On Jun 6, 11:34 am, Paul Kinlan  wrote:
> Hi,
> I believe the access_token last indefinitely (or at least a very very long
> time).  The request token is very short lived though.
>
> Paul
>
> 2009/6/6 Wallace 
>
>
>
> > Paul,
>
> > Ah, so you are saying that a token never expires?  I did not realize
> > that.  I had assumed that the token was specific to a given session or
> > timeframe.  I'm going to experiment with this and get back on this.
>
> > Wally
>
> > Paul posted in response to me
>
> > Hi Wallace,
> >http://www.Twollo.comdoes something similar to what you are
> > describing (it
> > hosted on the Google App Engine).  You can store the users oAuth
> > token
> > secret, access token (and request token if you don't have the access
> > token)
> > and then use these at a later date to send authenticated requests to
> > Twitter.  The good thing is that once you have the access token it is
> > unlikely to expire (unlike a users password) unless the user revokes
> > access
> > to your application.
>
> > Admittedly there is some user interaction, but it is only at the start
> > of
> > the process, much like the current process of asking for a users
> > username
> > and password. Once it is all done it is easy to make authenticated
> > requests
> > to Twitter without any user intervention.
>
> > This thread is mainly about the changes that were made to support
> > desktop
> > applications, but again, once the access token has been received the
> > same
> > applies as mentioned earlier.
>
> > Paul

[twitter-dev] oAuth in the cloud

[Wallace]

Paul,

Ah, so you are saying that a token never expires?  I did not realize
that.  I had assumed that the token was specific to a given session or
timeframe.  I'm going to experiment with this and get back on this.

Wally


Paul posted in response to me

Hi Wallace,
http://www.Twollo.com does something similar to what you are
describing (it
hosted on the Google App Engine).  You can store the users oAuth
token
secret, access token (and request token if you don't have the access
token)
and then use these at a later date to send authenticated requests to
Twitter.  The good thing is that once you have the access token it is
unlikely to expire (unlike a users password) unless the user revokes
access
to your application.


Admittedly there is some user interaction, but it is only at the start
of
the process, much like the current process of asking for a users
username
and password. Once it is all done it is easy to make authenticated
requests
to Twitter without any user intervention.


This thread is mainly about the changes that were made to support
desktop
applications, but again, once the access token has been received the
same
applies as mentioned earlier.


Paul

[twitter-dev] Re: OAuth Desktop Application Changes - Incompatibility Alert

[Wallace]

I wanted to follow up on this.  Admittedly, I'm a newb with oauth.
I'm currently working on an application that uses MS's cloud computing
environment Azure.  I'm using this to schedule tweets in the future.
Azure has a worker role which is an application that a web user never
directly works against.  The worker role is being used to post updates
to a user's stream.  Right now, I am using basic auth, but I would
like to move to oauth.  My current design has the user storing
twitterids and passwords in a table.  The user interacts over the web
with the webrole and then the worker role handles the posting.

It looks to me, given a VERY limited knowledge of oauth, that its
designed with user interaction in mind.  Does that sound correct?

Wally