twitter api server seems to be down (getting invalid signature) since 5.15 pm pst

[goodtest]

twitter api server seems to be down (getting invalid signature) since
5.15 pm pst

[João Pereira]

Same here.

[Doug Williams]

Marcel is shipping a fix for this as I type.

Thanks,
Doug

2009/7/27 João Pereira <joaomigue...@gmail.com>

[Doug Williams]

Updating you guys on this problem. A bug was reported off list that informed us we were not always verifying signatures. Today we shipped a fix for this problem which ensures that we are correctly verifying signatures. 

If you are still seeing invalid signature errors you should examine your code and ensure you are correctly signing requests as per the spec.

Thanks,
Doug

[chinaski007]

Doug:

Does this mean that Marcel made a fix for this? Or rather that we
should examine our code to find the culprit?

Thanks,
Peter Bray

On Jul 27, 6:24 pm, Doug Williams <d...@twitter.com> wrote:
> Updating you guys on this problem. A bug was reported off list that informed
> us we were not always verifying signatures. Today we shipped a fix for this
> problem which ensures that we are correctly verifying signatures.
> If you are still seeing invalid signature errors you should examine
> your code and ensure you are correctly signing requests
> as per the spec.
> Thanks,
> Doug
>

> On Mon, Jul 27, 2009 at 6:05 PM, Doug Williams <d...@twitter.com> wrote:
> > Marcel is shipping a fix for this as I type.
>
> > Thanks,
> > Doug
>

> > 2009/7/27 João Pereira <joaomiguel.pere...@gmail.com>
>
> > Same here.

[winrich]

mine broke too. i wonder though, i'm using the oauth python libraries

[Doug Williams]

If you are still seeing errors you should check your code to ensure that you are sending the correct signature.

Thanks,
Doug

[Duane Roelands]

Still seeing errors, but only when trying to post. Not when reading.

[goodtest]

Are we sure there is no further regression bug in this new fix?

On Jul 27, 7:14 pm, Doug Williams <d...@twitter.com> wrote:
> If you are still seeing errors you should check your code to ensure that you
> are sending the correct signature.
> Thanks,
> Doug
>

[Duane Roelands]

I am receiving 401 (Unauthorized) when calling http://twitter.com/statuses/update.xml
and passing the following querystring:

oauth_consumer_key=[removed]
&oauth_nonce=912352&oauth_signature_method=HMAC-
SHA1&oauth_timestamp=1248748647&oauth_token=19068738-
hKO8qRlHPfJWqRHRkd62dGb4IiyXaXUy35Cqz58&oauth_version=1.0&status=This
+is+a+test&oauth_signature=Fl0kqJdHY5MkvxjUZQ%2bFn%2fxGORo%3d

This code was working this afternoon and has not been changed.

[kosso]

same here. all was working fine (using abraham's php scripts linked
from the examples) - has not been working for the past couple of
hours.



On Jul 27, 7:44 pm, Duane Roelands <duane.roela...@gmail.com> wrote:
> I am receiving 401 (Unauthorized) when callinghttp://twitter.com/statuses/update.xml

[Doug Williams]

As stated above, some applications were sending invalid signatures which we were accepting as valid. This vulnerability was pointed out by a developer.

Some libraries and code which may have previously worked may be broken by this security fix.

Thanks,

Doug

[Duane Roelands]

You introduced a breaking change into the API with no warning and no
help for developers as to the specifics of what we need to fix?
Developers need better support than that.

Is there some reason why posting updates to some accounts would work
and posting to others would not? Using the same code, I'm able to
post to my development test account but not to my personal account.

On Jul 27, 10:59 pm, Doug Williams <d...@twitter.com> wrote:
> As stated above, some applications were sending invalid signatures which we
> were accepting as valid. This vulnerability was pointed out by a developer.
>
> Some libraries and code which may have previously worked may be broken by
> this security fix.
>
> Thanks,
> Doug
>

[kosso]

agreed.

please Twitter, tell us WHAT the fix required was.
what should we look for.

have you tested your 'fix' against all the code examples you link from
the API pages?

that would be nice. thx.


I'm getting some posts through. some not. so something's still up/down

[goodtest]

Yeah, I agree, can you please point out what (in general) we might be
doing wrong? I still think you probably have a further-regression bug.

[Chad Etzel]

I would start by looking at the OAuth spec at Section 9 - Signing Process.

http://oauth.net/core/1.0a#signing_process

In fact, if you (meaning everyone) have never read the whole spec, you need to.

-Chad

[chinaski007]

This is frustrating for those of us relying on authentication
libraries which now may no longer work. The apparent solution is to
either recode the possibly problematic library oneself, or encourage
users to swap to Basic Authentication.

While I certainly understand Twitter's need to ensure that everything
is secure on their end, this is another unannounced API change (like
the verify_credentials limit last week) that leaves some of us in the
lurch.

On Jul 27, 8:35 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> I would start by looking at the OAuth spec at Section 9 - Signing Process.
>
> http://oauth.net/core/1.0a#signing_process
>
> In fact, if you (meaning everyone) have never read the whole spec, you need to.
>
> -Chad
>

[Duane Roelands]

"I would start by looking at the OAuth spec at Section 9 - Signing
Process. "

RTFM is not a helpful answer, especially when many developers are
relying on libraries that they did not write. It's not unreasonable
to expect some advance notice on breaking changes to the API or
guidance on what specifically was changed.

[Bojan Rajkovic]

On Mon, 2009-07-27 at 20:55 -0700, Duane Roelands wrote:
> "I would start by looking at the OAuth spec at Section 9 - Signing
> Process. "
>
> RTFM is not a helpful answer, especially when many developers are
> relying on libraries that they did not write. It's not unreasonable
> to expect some advance notice on breaking changes to the API or
> guidance on what specifically was changed.
>
>
>
>
> On Jul 27, 11:45 pm, chinaski007 <chinaski...@gmail.com> wrote:
> > This is frustrating for those of us relying on authentication
> > libraries which now may no longer work. The apparent solution is to
> > either recode the possibly problematic library oneself, or encourage
> > users to swap to Basic Authentication.
> >
> > While I certainly understand Twitter's need to ensure that everything
> > is secure on their end, this is another unannounced API change (like
> > the verify_credentials limit last week) that leaves some of us in the
> > lurch.
> >
> > On Jul 27, 8:35 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> >
> >
> >
> > > I would start by looking at the OAuth spec at Section 9 - Signing Process.
> >
> > >http://oauth.net/core/1.0a#signing_process
> >
> > > In fact, if you (meaning everyone) have never read the whole spec, you need to.
> >
> > > -Chad
> >
> > > On Mon, Jul 27, 2009 at 11:31 PM, goodtest<goodtest...@gmail.com> wrote:
> >
> > > > Yeah, I agree, can you please point out what (in general) we might be
> > > > doing wrong? I still think you probably have a further-regression bug.

I'm with Duane here, some advanced notification of what's changed would
be nice--my OAuth library code worked up until a few days ago, and now
is suddenly failing with "incorrect signature" responses. It would be
nice to know what exactly causes this without having to go read the
specification head to toe to figure it out. A cryptic RTFM is not
helpful.

--
Bojan Rajkovic <boj...@brandeis.edu>
Biochemistry '10, Brandeis University
PGP Signature Key ID: 0x8783D016
PGP Encryption Key ID: 0x2497B8B2

[chinaski007]

It appears that this has been a known issue for 10 days, at least
judging by this tweet:

http://twitter.com/timwhitlock/statuses/2697185141

[Bojan Rajkovic]

Hmm. Seems to be a false alarm on my part, since tweeting works--I had
seemingly forgotten to URL-encode something when I was testing the OAuth
process by hand (my Twitter.API library does the URL encoding
programmatically, and sending a tweet via it worked fine).

My point about announcing changes and making what's changed more
explicit still remains though.

[Chad Etzel]

On Mon, Jul 27, 2009 at 11:55 PM, Duane
Roelands<duane.r...@gmail.com> wrote:
> RTFM is not a helpful answer, especially when many developers are
> relying on libraries that they did not write.

That's a risk you run when using code you didn't write.

I'm not saying that this situation doesn't suck for those affected.
I'm sure that it does. But, for a technology so new as OAuth, the
libraries may not be mature yet.

Officially, Twitter OAuth is still in Public Beta and has never been
officially recommended to integrate into production code. That being
said, there could still be a problem on Twitter's end with their
signature verification mechanism and the libraries could all be valid.
I don't have a way of knowing.

I do agree that at least a note that "a security change was pushed
today" would be nice, though.

-Chad

[winrich]

ok guys.

so my calls were failing on the verify_credentials call and not on the
update or timeline calls. the only difference i saw was the the
verify_credential call wasn't secured. i changed it to https and it
worked. ??? lol

On Jul 27, 9:19 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> On Mon, Jul 27, 2009 at 11:55 PM, Duane
>

[Doug Williams]

Please use the OAuth playground [1] to test your signatures against the expected result. I am working to gather specifics to help your debug process (i.e. what changed?) in the mean time.

1. http://googlecodesamples.com/oauth_playground/

Thanks,

Doug

[Duane Roelands]

From my experimenting, it appears that posting a tweet is successful
if the text contains no spaces. Once you have a space in the tweet,
it fails. Researching...

[Doug Williams]

If you are using a client library, please specify the library and version. There is a chance that you are all running into the same library-based incompatibility and could work together (or with the maintainer) to determine the fix.

Thanks,

Doug

[Duane Roelands]

Google OAuth Playground appears to be broken. Fill in the fields,
click "Get a Request Token", and the "Loading" spinner just spins
forever.

[goodtest]

btw, oauth_playground seems to be down as well.

Also, I don't understand why create account which uses the same core
method to create signature works but none of the other methods
(friends_timeline, update statuses) dont work :( waiting for some
hints

On Jul 27, 9:40 pm, Doug Williams <d...@twitter.com> wrote:
> Please use the OAuth playground [1] to test your signatures against the
> expected result. I am working to gather specifics to help your debug process
> (i.e. what changed?) in the mean time.

> 1.http://googlecodesamples.com/oauth_playground/
>
> Thanks,
> Doug

[goodtest]

BTW, I am using oauth Javascript client library(
http://oauth.googlecode.com/svn/code/javascript/ ) to create
signature. Wondering if it has a bug?

[srikanth reddy]

I dont think it has any bug (i have not verified this fix yet). I think the fix is actually for this problem
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297/9f4b9249f9ff96be?lnk=gst&q=consumer+secret#9f4b9249f9ff96be

Need to verify that the parameters are signed by both consumer secret and access secret.

[goodtest]

>Need to verify that the parameters are signed by both consumer secret and
access secret.

I am doing that already. For example, when I call
http://twitter.com/statuses/friends_timeline.json, I pass
consumerSecret, tokenSecret...
Using the JS library, it looks like this to get the signature:

var accessor = { consumerSecret: this.consumerSecret
, tokenSecret : <token_secret>};
var message = { method: "GET"
, action: "http://twitter.com/statuses/friends_timeline.json"
, parameters: new Array()
};
message.parameters.push(["oauth_consumer_key",this.consumerKey]);
message.parameters.push(["oauth_version","1.0"]);
message.parameters.push(["oauth_timestamp", OAuth.timestamp()]);
message.parameters.push(["oauth_nonce", OAuth.nonce(11)]);
message.parameters.push(["oauth_signature_method", "HMAC-SHA1"]);
message.parameters.push(["oauth_token", <auth_token>]);
OAuth.SignatureMethod.sign(message, accessor);
var signature = OAuth.getParameter(message.parameters,
"oauth_signature");

[srikanth reddy]

@goodtest
Hi Post methods (that require auth) seem to be working fine.
I am stuck with GET (problem with parametrs). checking whether the problem is incorrect usage of library  or the problem with library.
will let u know

[srikanth reddy]

Hi
After getting the access tokens i used the sample "echo.html" provided by JS library
Both GET and POST (that require auth and with parameters) are working fine. We just need to follow the same code

[kosso]

my problems are opposite (using some php scripts) verification is ok,
tweeting ok, but verified timelines (friends and mentions) not ok.

[iphone.noob]

How about letting us know what the changes were...? Apparently I am
one of the developers not correctly submitting signatures. I
developed my code based on samples in your wiki, and have no clue what
is broken with my authentication code (which has been working
perfectly for some time.)

[iphone.noob]

No doubt. This is super frustrating.

On Jul 27, 8:19 pm, kosso <kos...@gmail.com> wrote:

[Tim Goddard]

Inadequate notification of this issue has just wasted a full day of my
time. I'm guessing you're not releasing details to protect the other
OAuth service providers. Did you think that this is at the same time
damaging consumers? At least give notification of fixes once you've
'fixed' them even if you decide not to release warning in advance. You
have acted irresponsibly towards your developer community yet again,
as the sentiments in the other comments make clear.

Tim

On Jul 28, 3:35 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> I would start by looking at the OAuth spec at Section 9 - Signing Process.
>
> http://oauth.net/core/1.0a#signing_process
>
> In fact, if you (meaning everyone) have never read the whole spec, you need to.
>
> -Chad
>

[Interfecus]

I can confirm that Perl's Net::OAuth 0.9-1 is working with this. I had other issues (was half way through implementing an interface when this changed - threw me way off track) but the library should work unchanged. I was having trouble with the inital request token retrieval. Users of this library should make sure to set the token and token secret to "" for this part of the process.

Cheers,

Tim

--
<a href="http://www.spreadfirefox.com/?q=affiliates&amp;id=81126&amp;t=82"><img border="0" alt="Get Firefox!" title="Get Firefox!" src="http://sfx-images.mozilla.org/affiliates/Buttons/80x15/white_1.gif"/></a>

[Zaudio]

Mine were all to do with urlencoding, and ensuring all post data is
sent as post data, and none on the querystring for the URL; and thus
ensuring I use the modified URLencoding method required for Oauth -
which was previously being used, but not on the post data!

Once I did that, that test updates with all sorts of characters now
succeed every time... including spaces < > & etc etc

Seems good now... hope it stays that way!

Good luck to you guys!

[ant...@cloudangels.com]

@Doug - Can you confirm that it is now MANDATORY to supply both access
token and access secret as well as the consumer key and consumer
secret to generate a valid signature? OAuth spec states in #4 that
consumer secret may be empty if no consumer verification is neeeded.

------[excerpt from spec]------
"Service Providers SHOULD NOT rely on the Consumer Secret as a method
to verify the Consumer identity, unless the Consumer Secret is known
to be inaccessible to anyone other than the Consumer and the Service
Provider. The Consumer Secret MAY be an empty string (for example when
no Consumer verification is needed, or when verification is achieved
through other means such as RSA)."
------[end excerpt from spec]------

This would mean that you'd have to ship the customer secret to the
client with each deliverable you publish, regardless of whether you
want to do client verification or consumer (i.e. Server) verfication.

best regards,
Toni

[srikanth reddy]

Hi
i think now both access secret and consumer secret are required. i verified this by giving blank consumer secret and valid access secret and i got invalid signature error. It works fine when i give correct values for both. Looks like there is no way you can protect your consumer secret

[João Pereira]

I'm also frustrated.

I can't have a consistent behaviour from twitter API. Now works fine then give invalid signature for all users, then works again, can't understand grrrr

Moreover, for the same user, using the same code for authentication, some call works and others don't.

When will you guys at twitter get this back working?

[Duane Roelands]

I've been providing both consumer keys since I started using OAuth for
Twitter, and I'm still encountering issues because of this change.
This is frustrating beyond words.

On Jul 28, 7:03 am, João Pereira <joaomiguel.pere...@gmail.com> wrote:
> I'm also frustrated.
>
> I can't have a consistent behaviour from twitter API. Now works fine then
> give invalid signature for all users, then works again, can't understand
> grrrr
>
> Moreover, for the same user, using the same code for authentication, some
> call works and others don't.
>
> When will you guys at twitter get this back working?
>

> On Tue, Jul 28, 2009 at 11:53 AM, srikanth reddy <srikanth.yara...@gmail.com

>
>
>
> > wrote:
> > Hi
> > i think now both access secret and consumer secret are required. i verified
> > this by giving blank consumer secret and valid access secret and i got
> > invalid signature error. It works fine when i give correct values for both.
> > Looks like there is no way you can protect your consumer secret
>

[soup]

Indeed very frustrating.. developers also has a life haha.. i hope.

My day was gone because of this..

All my GET's work, only POST is not working... using PHP to generate
the sig.

Any good ideas yet?

[Hedley Robertson]

This is so clown show.

[BlueSkies]

I'm the developer who reported this problem to Twitter offline. I had
been preparing a test case for them when I noticed this post:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297?hl=en#

I then skipped the preparation of the test case and sent e-mail
directly to Twitter since this was what I considered to be a high risk
issue.

Since the fix from Twitter went in for this last night, I have also
seen some strange behaviour with OAuth. I'm getting a lot of 401
responses for users who were already logged in. I'm also getting
sporadic bad responses for accesses that ask for a request token (BTW
- I'm using https if that makes any difference).

I think that there is still a problem. I've switched my application
back to using Basic Auth for now.

- Scott
@scott_carter
http://bigtweet.com

[Zaudio]

I don't myself think that twitter are doing anything more than
enforcing the standard. I spent 3 hours 'fixing' my code for our
application (uses Shannon Whitley's c# library as a base); I only
found two bugs in thelibrary that caused any problem... the use of
httputility.urlencode in place of the modified urlencode already
implemented for use with Oauth, as required by the spec... the library
just wasn't using it in two places.
Following that, I found I was passing some bad strings to the
library... so the methods in it were not urldecoding and re-
urlencoding the postdata as required to get it to meet the spec. Once
I fixed that also, all seems good.

So if our app now posts all data fine over Oauth, it suggests that
twitter's interface is OK?

Simon

On Jul 28, 8:16 am, BlueSkies <scarter28m-goo...@yahoo.com> wrote:
> I'm the developer who reported this problem to Twitter offline. I had

> been preparing a test case for them when I noticed this post:http://groups.google.com/group/twitter-development-talk/browse_thread...

[goodtest]

I think the big problem is that twitter's implementation is buggy and
given that its relatively convoluted to implement oauth, even our
implementation is buggy. Adding to that if we only get 'invalid
signature' irrespective of which side the bug resides, frustrating
both sides.

I think it would be better they give 'clear' and concrete oauth
examples for various twitter api calls(few POSTs and few GETs). And
more importantly, also list out all the 'gotcha' or common-mistakes
would be better for all of us.

[Duane Roelands]

My stuff is based on Shannon Whitley's as well. Do you mind sharing
where specifically you had to make the changes?

[Cristovão Morgado]

I use this implementation:

http://www.codingthewheel.com/archives/codingthetweet

works flawlessly!

--
Cristovao Morgado
aka Saintr
http://www.oMeuJogoUsado.com
http://www.TweetaPorSMS.com
http://twitter.com/TheSaintr

[Duane Roelands]

Yeah, that's what I'm doing as well.

I wish Twitter would give us some answers.

I can post a tweet is the text is "test"
If I try to post "test!", it fails. Something about the encoding of
non-alphanumeric characters is part of the problem. But, because
Twitter isn't talking, all we can do is guess.

On Jul 28, 12:52 pm, Cristovão Morgado <cristovao.morg...@gmail.com>
wrote:

> I use this implementation:http://www.codingthewheel.com/archives/codingthetweet
>
> works flawlessly!
>

[Abraham Williams]

If you are encoding properly according to: http://oauth.net/core/1.0a#encoding_parameters and it still fails to update post and update to http://code.google.com/p/twitter-api/issues/entry and make Twitter fix it.

I've not double checked to verify but "!" should encode to "%21" and then it should work.

Abraham

--
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.

[Marcel Molina]

As many of you have since learned, we deployed an unannounced security fix that has resulted in unexpected failures for quite a few developers using OAuth. A developer reported to us that OAuth signatures were not being verified on our side. The fix was implemented and pushed on Sunday then deployed yesterday. Once the fix was in the wild many applications started returning Invalid Signature errors. Our various successful tests seem to indicate that the signature verification is implemented correctly and yet many people are experiencing errors. So what's going on?

One of the main problems seems to be that many OAuth libraries appear to not be generating correctly signed requests. It's likely that Twitter's implementation was used to test out many of these libraries when they were being implemented. Without the correct signature check, it appeared to these developers that their libraries were implementing the spec correctly. For this confusion we must take at least partial blame.

The following email from Simon in the UK seems to indicate absent url encoding and decoding is a likely culprit in many of these libraries: 

"I don't myself think that twitter are doing anything more than

enforcing the standard. I spent 3 hours 'fixing' my code for our

application (uses Shannon Whitley's c# library as a base); I only

found two bugs in thelibrary that caused any problem... the use of

httputility.urlencode in place of the modified urlencode already

implemented for use with Oauth, as required by the spec... the library

just wasn't using it in two places.

Following that, I found I was passing some bad strings to the

library... so the methods in it were not urldecoding and re-

urlencoding the postdata as required to get it to meet the spec. Once

I fixed that also, all seems good.

So if our app now posts all data fine over Oauth, it suggests that

twitter's interface is OK?"

There are at least several things we could have done better in dealing with this:

* We should have, it goes without saying, had more extensive test coverage of our implementation ensuring that we were fully implementing the spec so that the whole situation would have been avoided in the first place. 

* We should have had an email prepared to send out immediately following the deploy explaining the vulnerability and the change that was deployed, encouraging developers to double check that their signatures were in fact being generated correctly. 

We left a lot of people guessing for half a day, in many cases probably frantically trying to fix mysterious failures in their apps. For that we must admit guilt. We hadn't anticipated that so many libraries might have not been generating signatures correctly. As a result it didn't occur to us to urgently send out details, assuming fully implemented libraries would continue to work transparently and malicious requests would start to fail. We had been focusing our efforts first and foremost on getting the fix implemented and deployed to protect everyone. Lesson learned. We'll take this experience with us and bring it to bear next time such a situation arises.

We're going to do a post-mortem on our side to identify all the things we should have done better. We've read all of your feedback about how this could have been done better. To everyone who has chimed into this thread offering details and help, we extend our thanks.

--
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[goodtest]

@Marcel,
Thanks for the post.
Here are my suggestions:
- Please make 'concrete' API examples(few POSTs and few GETs) with
actual requests.
- Make a list common-mistakes that a developer might make while he
develops twitter appln(you know.. encoding, not-double-encoding, use
additional-params-for-signature-generation-if-any etc)
- A oauth sandbox where it throws "precise errors/feedbacks" for
developers to debug and test their apps would be very helpful as well.

> On Tue, Jul 28, 2009 at 10:28 AM, Abraham Williams <4bra...@gmail.com>wrote:
>
>
>
> > If you are encoding properly according to:

> >http://oauth.net/core/1.0a#encoding_parametersand it still fails to

> > update post and update to

> >http://code.google.com/p/twitter-api/issues/entryand make Twitter fix it.

>
> > I've not double checked to verify but "!" should encode to "%21" and then
> > it should work.
>
> > Abraham
>

[Cameron Kaiser]

> @Marcel,
> Thanks for the post.
> Here are my suggestions:
> - Please make 'concrete' API examples(few POSTs and few GETs) with
> actual requests.
> - Make a list common-mistakes that a developer might make while he
> develops twitter appln(you know.. encoding, not-double-encoding, use
> additional-params-for-signature-generation-if-any etc)
> - A oauth sandbox where it throws "precise errors/feedbacks" for
> developers to debug and test their apps would be very helpful as well.

I think these are excellent ideas.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- In memory of Werner Klemperer ----------------------------------------------

[Isaiah]

* We should have, it goes without saying, had more extensive test coverage of our implementation ensuring that we were fully implementing the spec so that the whole situation would have been avoided in the first place. 

More testing is always a good goal if feasible.  However, no spec is perfectly complete, thus no spec is perfectly stable.  And no implementation is perfect, thus no implementation is perfectly stable.

Suggesting that your implementation be perfect next time as a solution to your current instability might not be the best takeaway here.  It seems to me that the takeaway is that instability exists and our (twitter and the dev community) system for dealing with it was too fragile.

Being constructive:  Perhaps an API release mechanism that can withstand a bit of instability is worth investigating.

* We should have had an email prepared to send out immediately following the deploy explaining the vulnerability and the change that was deployed, encouraging developers to double check that their signatures were in fact being generated correctly. 

While I don't disagree at all, why wait until after?

While the number of apps that use the twitter api is many, the number of libraries is few.  Perhaps a private list to their primary maintainers is worth investigation.  Even if it was just the primaries from the list of libraries on your site:  http://apiwiki.twitter.com/OAuth-Examples

They might have given you a little warning of the likely panic.  Perhaps not enough time to change, but at least enough time to soften the blow with some information.

We're going to do a post-mortem on our side to identify all the things we should have done better. We've read all of your feedback about how this could have been done better. To everyone who has chimed into this thread offering details and help, we extend our thanks.

Not to let this post get too technical -- but my current released code ( OAuth_ObjC_Test_App ) seems to work (e.g. it checks and posts without any problems that I notice), however I'm not entirely sure what corner cases might trigger the failures.  If anyone has an idea of what regressions to run, I'd appreciate any info.  Thanks.

Isaiah

[JDG]

oh god yes. ESPECIALLY the last one.

--
Internets. Serious business.

[chinaski007]

Ugh, terrible situation here. Things working 99.9% of the time now
with Perl. But we continue to get bizarre intermittent errors that
span the range of API calls. We are thinking that internal hash re-
ordering may invalidate signatures, but that is just speculation.

[goodtest]

If it works 99.9% of the times and breaks intermittently, its 1000%
encoding issue and nothing else - your signature or some-data is
having few characters that's not encoded in that particular instance.

[BlueSkies]

I think goodtest is correct.

Please see my post at:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/27f991f752786843?hl=en

It may be relevant to your Perl problems.

- Scott
@scott_carter

[Andreu]

I read this discussion carefully and I cannot extract a conclusion...

The question is why a set of API methods are working and others aren't
working properly, returning a 'Incorrect signature' error.

Methods working now:
- posting a tweet (statuses/update). Works fine
- extract user timeline (statuses/user_timeline). Works fine either
the request is made by the authenticated user (user requesting his own
timeline) or requesting a 3rd user timeline
- verify credentials (account/verify_credentials). Works fine.

Methods not working:
- delete a tweet (statuses/destroy).
- destroy a relationship (friendships/destroy)
- create a relationship (friendships/create)
- extract friends timeline (statuses/friends_timeline)

All methods are relying over the same base python method, building the
same requests changing the API urls and/or parameters... The library I
am using is http://oauth.googlecode.com/svn/code/python/oauth/oauth.py

I think if server signature verification have been modified, and now
is running 'properly', all my methods should fail, especially the
methods that authentication is required... but the problem is ones are
working and others not working.

[Chris Kimpton]

@noradio - thanks for the notification, belated though it was.

FWIW I am using the OAuthConsumer Objective-C library - http://code.google.com/p/oauthconsumer/

Its already behind with the verifier change, but there are posts the FAQ on how to get it working with that and now this change.

The fix this time involved only sending the "oauth_verifier=" part when a non-empty verifier is available.  Not sure why thats a fix - or if its a complete fix... but I can post from my app again :)

Regards,
Chris

2009/7/28 Doug Williams <do...@twitter.com>

If you are using a client library, please specify the library and version. There is a chance that you are all running into the same library-based incompatibility and could work together (or with the maintainer) to determine the fix.

[AlbertC]

I don't know if this will help at all, but I had the same
problem...after hours spent on this stupid error, I realized that some
of my request URLs were using http, and some https.
After changing all the request URLs to https, everything's working
perfectly (I'm using exactly the same client library). It does make
all kinds of sense.

Regular http requests worked fine before, though.

It's probably been mentioned before. If so, I missed it, sorry. :)

On Jul 30, 12:03 pm, Andreu <andreup...@gmail.com> wrote:
> I read this discussion carefully and I cannot extract a conclusion...
>
> The question is why a set of API methods are working and others aren't
> working properly, returning a 'Incorrect signature' error.
>
> Methods working now:
> - posting a tweet (statuses/update). Works fine
> - extract user timeline (statuses/user_timeline). Works fine either
> the request is made by the authenticated user (user requesting his own
> timeline) or requesting a 3rd user timeline
> - verify credentials (account/verify_credentials). Works fine.
>
> Methods not working:
> - delete a tweet (statuses/destroy).
> - destroy a relationship (friendships/destroy)
> - create a relationship (friendships/create)
> - extract friends timeline (statuses/friends_timeline)
>
> All methods are relying over the same base python method, building the
> same requests changing the API urls and/or parameters... The library I

> am using ishttp://oauth.googlecode.com/svn/code/python/oauth/oauth.py

[Jonathan@ScribbleLive]

I may be the only one to be this stupid, but when I looked at my POST
request functions, I was appending some parameters like "Source", etc.
that were common to all requests. But since they weren't there when
the signature was generated, we were getting 401 errors as of 7/27.
Removing those fixed us right up.

--Jonathan

On Jul 28, 12:46 am, Duane Roelands <duane.roela...@gmail.com> wrote:
> From my experimenting, it appears that posting a tweet is successful
> if the text contains no spaces.  Once you have a space in the tweet,
> it fails.  Researching...
>

> On Jul 28, 12:29 am, winrich <winric...@gmail.com> wrote:
>
> > ok guys.
>
> > so my calls were failing on the verify_credentials call and not on the
> > update or timeline calls. the only difference i saw was the the
> > verify_credential call wasn't secured. i changed it to https and it
> > worked. ??? lol
>
> > On Jul 27, 9:19 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
>

> > > On Mon, Jul 27, 2009 at 11:55 PM, Duane

[Isaiah]

After all this discussion, I'm a bit nervous that I may missed something that needs to be fixed.  Does anyone know of a good testcase that will trigger the failures in the OAuthConsumer libs?

I've checked POST, seems to work as expected.

Tested odd encodings (like spaces and other things that need urlencoding), those seem OK too.

What am I missing?

Isaiah

YourHead Software

sup...@yourhead.com

http://www.yourhead.com

[Andreu Pere]

Oh yes!!! The methods which didn't work were sent by plain HTTP and the other methods that work ok were using HTTPS.... didn't mind!!

Now, all methods are working on HTTPS, and all are working properly!! Sure, it seams the solution is use HTTPS

Thanks!!

[Andreu]

Oh yes!!! The methods which didn't work were sent by plain HTTP and
the other methods that work ok were using HTTPS.... didn't mind!!

Now, all methods are working on HTTPS, and all are working properly!!
Sure, it seams the solution is use HTTPS

Thanks!!