OAUTH seems to have broken?

mrcfield
@mrcfield Chris Field

Since last night (its 9am here in the UK) something seems to have changed with Twitter's OAUTH?

My code was working fine last night, now requesting tokens gives complete nonsense. This is even on an app that was published for several weeks, so there's no way I could have changed anything.

This is what I'm seeing returned : http://twitpic.com/7w6x99

2 years 17 weeks ago

Replies

deepra_uk
@deepra_uk Deepra Ltd

Same thing happening to me too.. Any solutions?

2 years 17 weeks ago
episod
@episod Taylor Singletary

This would be quite unusual. Can you detail the HTTP headers you're sending with the request and the HTTP headers you're getting in response?

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

Thanks for the reply.

I can't easily unfortunately as I can't get Fiddler working with the Windows Phone SDK. Currently "at work", but will try and get some header info later on.

I noticed in the screenshot it was set to a GET ,and probably should be a POST... I had tried that too and that gave the same results.

2 years 17 weeks ago
episod
@episod Taylor Singletary

Were you operating through any kind of proxy?

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

None other than any my ISP may be running (which is virgin media).

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

The users of my application have started reporting the same issue, so I doubt its a proxy issue.

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

Just running further tests, and it works sometimes, and not others. I don't know if there is some kind of load balancing issue where by one of the machines in the cluster is "dodgy"?

I'm passing in the same data each time...

2 years 17 weeks ago
episod
@episod Taylor Singletary

Not usually -- but that's why I want to see your HTTP headers you get in a response and that you send -- they'll tell us where to look for issues.

2 years 17 weeks ago
Testing1500
@Testing1500 Tony

I'm getting the same, here's the response headers from https://api.twitter.com/oauth/access_token

HTTP/1.1 401 Unauthorized
WWW-Authenticate: OAuth realm="https://api.twitter.com"
X-Transaction: 7b0da5a2a458dadc
Content-Length: 131
X-MID: b20cf2f03f9c851a982571c5402af8ccfe1bffda
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Wed, 21 Dec 2011 17:52:42 GMT
X-Revision: DEV
Set-Cookie: _twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCC71wGE0AToHaWQiJWI2MTkyZjc2ZTFjY2Iw%250AZWZhN2ZlZjU2YzAwODg5OGZjIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy%250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--325f603876b34bffe49654fc8b6be3da780cc86d; domain=.twitter.com; path=/; HttpOnly
Set-Cookie: guest_id=v1%3A132448996279749387; domain=.twitter.com; path=/; expires=Sat, 21-Dec-2013 05:52:42 GMT
Set-Cookie: k=10.34.122.103.1324489962743367; path=/; expires=Wed, 28-Dec-11 17:52:42 GMT; domain=.twitter.com
Server: tfe
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Pragma: no-cache
Status: 401 Unauthorized
X-Frame-Options: SAMEORIGIN
Date: Wed, 21 Dec 2011 17:52:42 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8

  1. <hash>
  2.   <error>Invalid / expired Token</error>
  3.   <request>/oauth/access_token</request>
  4. </hash>

As per the other poster this functionality was working in several environments up until today where these exceptions are occurring.

2 years 17 weeks ago
rschu
@rschu René Schulte

Same here.

It's broken. There's no access token returned.

2 years 17 weeks ago
episod
@episod Taylor Singletary

Some folks here are reporting a separate issue to the originating post.

If you're having trouble negotiating OAuth, please share the exact URLs you're executing and include the POST body and all HTTP headers sent and received.

If you're having issues with oauth/access_token in particular, detail the amount of time that passed between the oauth/request_token step and your utilization of oauth/access_token.

2 years 17 weeks ago
rschu
@rschu René Schulte

Here's a dump of the response I get:
http://pastebin.com/6kFL85ch

You can find the URIs, request, response time, headers and more info. Hope this helps.

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

Mine is the same as René's

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

Here are the headers I get back:

Date: Wed, 21 Dec 2011 19:40:08 GMT
Status: 200 OK
X-Transaction: d849eb9ba2b89634
ETag: "7346f04d31ae37daf42612d4d4dec3b5"
X-Frame-Options: SAMEORIGIN
Last-Modified: Wed, 21 Dec 2011 19:40:08 GMT
X-Runtime: 0.12137
Content-Type: text/html; charset=utf-8
Content-Length: 163
Pragma: no-cache
X-Revision: DEV
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
X-MID: 677e8f1f834f063956142da9c08d959300172d84
Set-Cookie: k=10.35.19.120.1324496408317801; path=/; expires=Wed, 28-Dec-11 19:40:08 GMT; domain=.twitter.com, guest_id=v1%3A132449640832492020; domain=.twitter.com; path=/; expires=Sat, 21-Dec-2013 07:40:08 GMT, original_referer=fBxhJyK4Ko2le28vCjFdUuU0TPqFAtRd5Sf5c5QBb4gTOUJXdRr%2B8fMpzo5i43qdtpdBso14k8sdRdYbr1UTTi5N7Q9mLoRp%2BlZcLoynFik%3D; path=/, external_referer=fBxhJyK4Ko2le28vCjFdUuU0TPqFAtRd5Sf5c5QBb4gTOUJXdRr%2B8fMpzo5i43qdtpdBso14k8sdRdYbr1UTTi5N7Q9mLoRp%2BlZcLoynFik%3D%7C0; path=/; expires=Thu, 22-Dec-2011 19:40:08 GMT
Vary: Accept-Encoding
Server: tfe

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

And these are the headers I send... I have removed a few bits though (I think theyre the bits you're supposed to keep "secret"?)

Authorization: OAuth oauth_consumer_key="",oauth_nonce="",oauth_signature="SAFtiFZyFIGRYUqb6ddWFxFMiUs%3D",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1324499188",oauth_token="",oauth_verifier="27coffEwnLpf4INxCYa3lzriGhyavNh4SpIuu38g3H8",oauth_version="1.0"
Content-Type: application/x-www-form-urlencoded

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

Any further update on this? Still seems broken!

2 years 17 weeks ago
paulousky
@paulousky Max Paulousky

It seems all Windows Phone applications (except native Twitter app) that use Hammock library experience that issue (my PhotoTweet also).
If I debug authorization process, it works well but if I run the code without debugging - it does not work

Dear twitter devs, could you look into that issue ASAP? A lot of our users can't authenticate and use our applications because of that issue

UPD1:
I don't think it's an issue of Hammock library. Seesmic, TweetCaster, WindowsPhone news etc experience the same issue

Upd2: 90% of WinPhone twitter clients use Hammock. Something wrong with that lib
Will ask Hammock Devs

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

That's also my experience as well, stepping through the code more often than not seems to work, but running it doesn't. HAS to be some kind of timing issue.

(and yeah, my app uses Hammock too)

2 years 17 weeks ago
khamitimur
@khamitimur Timur Khamidov

same issue. but it's seems to work after several times auth page been refreshed.

also using hammock.

2 years 17 weeks ago
paulousky
@paulousky Max Paulousky

Asked Hammock devs
https://github.com/danielcrenna/hammock/issues/59

2 years 17 weeks ago
deepra_uk
@deepra_uk Deepra Ltd

Same issue here. Tried with my client, Seesmic, and it doesn't work for either.
I am getting a bunch of garbage characters as the response. Hope a solution is found for this ASAP.

2 years 17 weeks ago
deepra_uk
@deepra_uk Deepra Ltd

It appears that the problem is limited..
When I try to connect using Hootsuite's web application, the Oauth seems to work fine.

2 years 17 weeks ago
paulousky
@paulousky Max Paulousky

probably, it does not use hammock. Seesmic does

2 years 17 weeks ago
marco
@marco Marco Kaiser

Hi,

we noticed that we get gzip encoded data from the servers, which apparently breaks Hammock, even if we pass in 'Accept-Encoding: identity' - the response has 'Content-Encoding: gzip' set. I would consider that a violation of the HTTP protocol, no?

We also don't get this for all users - some actually are able to use our apps that use Hammock just fine, so this might be an issue only on some of the frontend API servers.

Thanks,
Marco

2 years 17 weeks ago
dotMorten
@dotMorten Morten Nielsen

I extended hammock to support gzip and I still see the problem

2 years 17 weeks ago
aeayala
@aeayala Adrian Ayala

I also I have problems with the api, sometimes I have no answer and I can show messages but not others.

2 years 17 weeks ago
aMikey_
@aMikey_ Michael Dekmetzian

I had a similar issue to this on a different endpoint, but found that the code that was calling twitter wasn't taking into account varying content types - ie it was not expecting a gzipped response. This code was working up until a couple of days ago, so presumably something was changed with respect to responses on the twitter side.

After updating our code to check the response content type (which it should have done regardless, probably) it now works fine, though your mileage may vary.

-Mike

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

Is anyone from Twitter investigating this at all?

2 years 17 weeks ago
dotMorten
@dotMorten Morten Nielsen

Actually I take my previous statement back. The particular OAuth process didn't use gzip encoding. I added gzip support to this as well, and it just started working again. So basically all you have to do is gzip decode if the response header says its encoded with gzip.
I would agree with what someone else who pointed out that returning gzip when not requesting gzip is breaking with the HTML spec.
I can also confirm the findings that it's not consistent when gzip is returned and when it isn't.

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

Same thing here. Getting back nothing but gibberish in my content callbacks.

2 years 17 weeks ago
episod
@episod Taylor Singletary

We're looking into this.

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

Hi there, any update on this?

2 years 17 weeks ago
rschu
@rschu René Schulte

Like Marco and Morten wrote, the response is sometimes GZip packed. Just check if the Content-Encoding header is "gzip" or the first two bytes of the response for the GZip magic number (0x1f8b). See http://tools.ietf.org/html/rfc1952#page-6

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

I would like an explanation from Twitter on this before I recode and submit an app update, only to have Twitter change it again and break it further.

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

From what I understand, @BrandonWatson is "reaching out internally on the twitter relationship". So fingers crossed for some kind of news soon.

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

That's good news.

2 years 17 weeks ago
rschu
@rschu René Schulte

The workaround is pretty straight forward and it's very very unlikely that this will affect your app in the future.
Just test if the header Content-Encoding == "gzip", if so, wrap the returned response stream in a GZipInputStream.

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

I am trying to figure out how to do that in a windows phone app now using the Hammock REST libary.

2 years 17 weeks ago
rschu
@rschu René Schulte

Me too. Here's the code snippet I use. See the part where I check for the encoding and wrap the stream in a GZip stream.

var oAuthWorkflow = new OAuthWorkflow
{
AccessTokenUrl = TwitterConstants.AccessTokenUrl,
ConsumerKey = EndpointData.TwitterConsumerKey,
ConsumerSecret = EndpointData.TwitterConsumerSecret,
SignatureMethod = OAuthSignatureMethod.HmacSha1,
ParameterHandling = OAuthParameterHandling.HttpAuthorizationHeader,
Version = TwitterConstants.OAuthVersion,
Token = OauthToken,
TokenSecret = OauthTokenSecret,
Verifier = verifyPin,
};

var info = oAuthWorkflow.BuildAccessTokenInfo(WebMethod.Post);
var oAuthWebQuery = CreateOAuthWebQuery(info);

oAuthWebQuery.QueryResponse += (s, e) =>
{
var stream = e.Response;
var webResponse = ((WebQuery)s).WebResponse;
if (webResponse != null)
{
// See if the encoding is GZip
if (webResponse.Headers["Content-Encoding"] == "gzip")
{
stream = new GZipInputStream(stream);
}
}
using (var reader = new StreamReader(stream, Encoding.UTF8))
{
var parameters = GetQueryParameters(reader.ReadToEnd());
AccessToken = parameters["oauth_token"];
AccessTokenSecret = parameters["oauth_token_secret"];
}
stream.Dispose();
};

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

Thanks - this is helpful - but I am using the Hammock RestClient (RestRequest and RestResponse). I may have to rewrite most if not all my code to request an access token.

2 years 17 weeks ago
ravikammaje
@ravikammaje Ravi

Thanks for this Rene..
@SMCApps - This works in Hammock as well.

2 years 17 weeks ago
nilayshah80
@nilayshah80 Nilay Shah

Thanks for the code, this really helpful.

2 years 17 weeks ago
kanal_7
@kanal_7 Kamalakannan

Hi

Me too facing the same issue for past week. I have tried with the work around given above.

Work around

  1.   var webResponse = ((WebQuery)sender).WebResponse;
  2.                 if (webResponse != null)
  3.                 {
  4.                     // See if the encoding is GZip
  5.                     if (webResponse.Headers["Content-Encoding"] == "gzip")
  6.                     {
  7.                         stream = new GZipInputStream(stream);
  8.                         using (var reader = new StreamReader(stream.ToString(), Encoding.UTF8))
  9.                         {
  10.                             var parameters = HelperMethods.GetQueryParameters(e.Response);
  11.                             accessToken = parameters["oauth_token"];
  12.                             accessTokenSecret = parameters["oauth_token_secret"];                         
  13.                         }
  14.                     }
  15.                 }

Still i'm getting the Response (e.Response) like encrypted one. Please see the image in the link .
http://alturl.com/ct33y

But i could not pass the stream in the Constructor as below .
stream = new GZipInputStream(stream);
Since it allows only Stream and i get the response as String here.

Is any update in library?

Thanks
Kamal.

2 years 16 weeks ago
ravikammaje
@ravikammaje Ravi

@aMikey_ - Can you please let us know what needs to be changed for handling gzip?
Thanks

2 years 17 weeks ago
aMikey_
@aMikey_ Michael Dekmetzian

as per René - Just test if the header Content-Encoding == "gzip" and handle the content appropriately, though what needs to be changed in your case depends on which language/implementation you're using.

2 years 17 weeks ago
mrcfield
@mrcfield Chris Field

I've implemented the work around too now also :(

It certainly seems, from my testing anyway, that the first attempt fails, then (while the browser still has the cookie) retrying again works. I've had this confirmed by several of my users too.

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

How did you implement the work-around?

2 years 17 weeks ago
ns730058
@ns730058 N S

I can't even re-create access token from the Application settings page on Twitter Site. Is something broken their as well.

2 years 17 weeks ago
cheekyTaurusWP
@cheekyTaurusWP cheekyTaurus

I caught a break...
Dim client = New RestClient() With { _
.Authority = "https://api.twitter.com/oauth", _
.Credentials = credentials, _
.HasElevatedPermissions = True, _
.SilverlightAcceptEncodingHeader = "gzip", _
.DecompressionMethods = Silverlight.Compat.DecompressionMethods.GZip _
}

2 years 17 weeks ago
khamitimur
@khamitimur Timur Khamidov

Thanks! Works great for me!

2 years 17 weeks ago