401 - Fixing server time differences?

NWatchAlerts · 2012-03-26T15:41:14.000Z

Hi All!

I’m using OAuth.php along with Abraham’s twitteroauth.php version 0.2.0.

The objective is to get my app authorized, store the credentials and do offline posting on the users behalf. I had all this working just fine and then we moved to a new set of servers and upgraded to PHP 5.3.1.

Yesterday I was able to hit the authorization page on twitter and give my app permission but it returned a 401 (see below). This morning we reset the server timezone to CST, changed the timezone in our php.ini to America/Chicago and rebooted and now we don’t even get the Twitter Authorization page, we just get an immediate 401.

I suspect this is all about some setting that Twitter needs for our server so I’m hoping someone will tell me the correct mod to make in OAuth.php->generate_timestamp();

The entries we’ve managed to capture in the error_log are:

[26-Mar-2012 14:43:12 UTC] callback.php: http_code - 401
[26-Mar-2012 14:43:12 UTC] callback.php: http_info - Array
(
    [url] => https://api.twitter.com/oauth/access_token?oauth_consumer_key=cxxxxxxxxxxxxxxxxxxxxxxx&oauth_nonce=xxxxxxxxxxxxxxxxxxxxxxx&oauth_signature=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1332772989&oauth_verifier=xxxxxxxxxxxxxxxxxxxxxxxxxx&oauth_version=1.0
    [content_type] => text/html; charset=utf-8
    [http_code] => 401
    [header_size] => 1005
    [request_size] => 381
    [filetime] => -1
    [ssl_verify_result] => 0
    [redirect_count] => 0
    [total_time] => 3.292677
    [namelookup_time] => 0.004509
    [connect_time] => 3.067823
    [pretransfer_time] => 3.208732
    [size_upload] => 0
    [size_download] => 1
    [speed_download] => 0
    [speed_upload] => 0
    [download_content_length] => 1
    [upload_content_length] => 0
    [starttransfer_time] => 3.29225
    [redirect_time] => 0
    [certinfo] => Array
        (
        )

    [redirect_url] => 
)

[26-Mar-2012 14:43:12 UTC] callback.php: http_status - 
[26-Mar-2012 14:43:12 UTC] callback.php: last_api_call - 
[26-Mar-2012 14:43:12 UTC] callback.php: request -

Thanks

episod · 2012-03-26T15:50:48.000Z

It’s preferable to just keep your server time in UTC so it’s agnostic to these kind of issues.

If you want to keep your clock set to CST, you’ll probably need to monkey patch the generate_timestamp method to first convert the local time to a UTC representation (using DST-aware time math) and then to the number of seconds since the epoch. There’s another approach where you adjust timestamps after the fact based on the date declared in error responses, but it’s best to take care of the issue before you send out an initial request.

NWatchAlerts · 2012-03-26T20:55:03.000Z

Yeah, that didnt work. We changed our server timezone to UTC, changed php.ini to Other/UTC, rebooted and nada… we’re getting nowhere with this.

Sad part for us is that it took 3 days to get the facebook code up and running and we’ve been screwing around with this for 3 weeks. It’s getting frustrating.

What’s the next thing to try?

episod · 2012-03-26T21:01:04.000Z

Are you just changing settings and then retrying auth or are you taking a disciplined approach to this? Are you looking at the response from the API – does it indicate that it’s a timestamp issue or perhaps something else?

Once you’ve changed your PHP and server settings, what are you doing to better understand the time values that you’re actually generating?

It is currently 1:57:57pm pacific daylight savings time on 03/26/2012. That’s 20:57:57 UTC and “1332795477” as epoch time in seconds.

NWatchAlerts · 2012-03-26T21:15:36.000Z

Frankly, we don’t know where to look for the problem. Like I said in my opening post, it was working, we moved to new servers with a slightly different configuration and php 5.3.x vs 5.2.x and in the move it stopped working.

At this point we’ve checked and double checked everything we can think of and we’re not even getting to the Twitter Authorize screen… we request “approval” and before the user ever sees that screen on Twitter our callback gets called with a 401 error.

episod · 2012-03-26T21:34:23.000Z

Make sure that your consumer keys and secrets are the same in both environments. We send back a HTTP header called “Date” in every response, both successful and erroneous, that will tell you exactly what time we consider it “to be” here. You want to make sure your clock is within about 5 minutes of that.

If you’re able to negotiate a request token and then move to the oauth/authorize step, it’s likely that your consumer keys and secrets are correct. If you’re a number of minutes behind on the clock, you might get oauth/request_token to work, but hasten the expiration of oauth/authorize.

[node:204] goes over several common things that can go wrong in OAuth. I really really recommend switching to header-based auth instead of the query-string based approach you’re taking now – it greatly separates concerns and lowers the chance of something minor going wrong.

NWatchAlerts · 2012-03-26T21:44:31.000Z

Will follow these individual steps first thing tomorrow…

gkbhardwaj88 · 2014-01-14T18:28:32.000Z

how to check twitter server time zone. Because i’m getting 401 unauthorized acces error while using twitter streaming api to consume public stream.