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!!
On Jul 30, 10:16 pm, AlbertC wrote:
> I
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!!
On Thu, Jul 30, 2009 at 10:16 PM, AlbertC
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 th
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
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 libra
@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
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 (st
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
On Jul 28, 3:42 pm, goodtest wrote:
> If it works 99.9% of the times and bre
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.
On Jul 28, 12:36 pm, chinaski007 wrote:
> Ugh, terrible situation here. Things working 99.9
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.
oh god yes. ESPECIALLY the last one.
On Tue, Jul 28, 2009 at 12:22, Cameron Kaiser wrote:
>
> > @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 de
* 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
> @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
> addit
@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
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
deploye
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 w
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
I use this implementation:
http://www.codingthewheel.com/archives/codingthetweet
works flawlessly!
On Tue, Jul 28, 2009 at 5:47 PM, Duane Roelands wrote:
>
> My stuff is based on Shannon Whitley's as well. Do you mind sharing
> where specifically you had to make the changes?
>
> On Jul 28, 11
My stuff is based on Shannon Whitley's as well. Do you mind sharing
where specifically you had to make the changes?
On Jul 28, 11:40 am, Zaudio wrote:
> I don't myself think that twitter are doing anything more than
> enforcing the standard. I spent 3 hours 'fixing' my code for our
> applicatio
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 b
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
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-mai
This is so clown show.
On Tue, Jul 28, 2009 at 5:57 AM, soup wrote:
>
> 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?
>
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?
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 wrote:
> I'm also frustrated.
>
> I can't have a consistent behaviour from twitter API. Now
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
g
Moreover, for the same user, using the same code for authentication, some
call works and others don't.
When will you guys
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
On Tue,
@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]
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 update
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
No doubt. This is super frustrating.
On Jul 27, 8:19 pm, kosso wrote:
> 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 gett
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
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.)
On Jul
my problems are opposite (using some php scripts) verification is ok,
tweeting ok, but verified timelines (friends and mentions) not ok.
On Jul 27, 9:29 pm, winrich wrote:
> ok guys.
>
> so my calls were failing on the verify_credentials call and not on the
> update or timeline calls. the only
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
On Tue, Jul 28, 2009 at 12:54 PM, srikanth reddy wrote:
> @goodtest
> Hi Post methods (that r
@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
On Tue, Jul 28, 2009 at 12:25 PM, goodtest wrote:
>
> >Need to verify that
>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:
I have found the problem in the library I am using: First, a Twitter
request object is created. Second, a signature is generated. Third,
params are then added to the request object. This addition of the
params after the signing invalidates the signature. All params need
to be added before sign
I have found the problem in the Perl library I am using.
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
BTW, I am using oauth Javascript client library(
http://oauth.googlecode.com/svn/code/javascript/ ) to create
signature. Wondering if it has a bug?
On Jul 27, 10:53 pm, goodtest wrote:
> btw, oauth_playground seems to be down as well.
>
> Also, I don't understand why create account which uses
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 wrote:
>
Google OAuth Playground appears to be broken. Fill in the fields,
click "Get a Request Token", and the "Loading" spinner just spins
forever.
On Jul 28, 12:46 am, Duane Roelands wrote:
> From my experimenting, it appears that posting a tweet is successful
> if the text contains no spaces. Once
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
On Mon, Jul 27, 2009 at 9:40 PM, Doug Williams wrot
>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 wrote:
> ok guys.
>
> so my calls were failing on the verify_credentials call and not on the
> update
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
On Mon, Jul 27, 2009 at 9:29 PM, winrich wrot
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 wrote:
> On Mon, Jul 27, 2009 at
On Mon, Jul 27, 2009 at 11:55 PM, Duane
Roelands 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.
On Tue, 2009-07-28 at 00:06 -0400, Bojan Rajkovic wrote:
> 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 librari
It appears that this has been a known issue for 10 days, at least
judging by this tweet:
http://twitter.com/timwhitlock/statuses/2697185141
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 a
"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 spe
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 tha
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 wrote:
>
> Yeah, I agree, can you please point
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.
On Jul 27, 8:19 pm, kosso wrote:
> agreed.
>
> please Twitter, tell us WHAT the fix required was.
> what should we look for.
>
> have you tested your 'fix'
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
On Jul 27, 8:04 pm, Duan
This is very frustrating.
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
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
On Mon, Jul 27, 2009 at 7:44 PM, Duane
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 wrote:
> I am receiving 401 (Unauthorized) when
> callinghttp://twitter.com/statuses/update.xml
> and passing the fol
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
Are we sure there is no further regression bug in this new fix?
On Jul 27, 7:14 pm, Doug Williams wrote:
> If you are still seeing errors you should check your code to ensure that you
> are sending the correct signature.
> Thanks,
> Doug
>
> On Mon, Jul 27, 2009 at 7:10 PM, winrich wrote:
>
> >
Still seeing errors, but only when trying to post. Not when reading.
On Jul 27, 10:14 pm, Doug Williams wrote:
> If you are still seeing errors you should check your code to ensure that you
> are sending the correct signature.
> Thanks,
> Doug
>
>
>
> On Mon, Jul 27, 2009 at 7:10 PM, winrich w
If you are still seeing errors you should check your code to ensure that you
are sending the correct signature.
Thanks,
Doug
On Mon, Jul 27, 2009 at 7:10 PM, winrich wrote:
>
> mine broke too. i wonder though, i'm using the oauth python libraries
>
> On Jul 27, 6:35 pm, chinaski007 wrote:
>
mine broke too. i wonder though, i'm using the oauth python libraries
On Jul 27, 6:35 pm, chinaski007 wrote:
> 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 William
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 wrote:
> Updating you guys on this problem. A bug was reported off list that informed
> us we were not always verifying si
Not sure if my message went through. I am also getting this error...
"incorrect signature" as of about 30 mins ago.
Any ideas???
On Jul 27, 5:26 pm, goodtest wrote:
> twitter api server seems to be down (getting invalid signature) since
> 5.15 pm pst
Yep, likewise. I am getting 100s of "incorrect signature" errors.
On Jul 27, 5:26 pm, goodtest wrote:
> twitter api server seems to be down (getting invalid signature) since
> 5.15 pm pst
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 an
Marcel is shipping a fix for this as I type.
Thanks,
Doug
2009/7/27 João Pereira
> Same here.
>
>
> On Tue, Jul 28, 2009 at 1:26 AM, goodtest wrote:
>
>>
>> twitter api server seems to be down (getting invalid signature) since
>> 5.15 pm pst
>
>
>
>
>
Same here.
On Tue, Jul 28, 2009 at 1:26 AM, goodtest wrote:
>
> twitter api server seems to be down (getting invalid signature) since
> 5.15 pm pst
71 matches
Mail list logo