Archive

Posts Tagged ‘api’

Handling “Session key invalid or no longer valid” errors from Facebook

September 10th, 2009
8 comments

I’m not sure if it’s supposed to work this way, but Facebook’s PHP client library method get_loggedin_user() doesn’t do the best job of keeping track of valid sessions. I seem to recall that even their demo FB Connect application experienced this error… It’s easy to reproduce on many FB Connect sites; log into a FB Connect site, then go to Facebook, logout of Facebook, and return to your FB Connect site. Reload the page and you’ll likely see a Session key invalid or no longer valid error followed by a trace.

So simple solution would be to catch the error; problem is that I don’t think it’s terribly obvious how to properly release the session if an error is caught… Using CakePHP, I added the following to my beforeFilter method:

if($this->facebook->get_loggedin_user()):
    try {
        $this->user = $this->facebook->api_client->fql_query('SELECT uid, pic_square, first_name FROM user WHERE uid = ' . $this->facebook->get_loggedin_user());
    } catch (Exception $ex) {
        $this->facebook->clear_cookie_state();
    }
endif;

So the only way to reliably test whether or not you have a valid session (since get_loggedin_user() can’t be trusted) is to run a method that requires one, and see if it throws an error. Sure, it adds overhead which is why I’d recommend a light FQL query which will return data I need anyway, but it’s much better than throwing fatal errors.

If an error is found, clear_cookie_state() seems to effectively destroy the session, and get_loggedin_user() will properly return false in all subsequent code.

kettle server-side , ,

Twitter’s API returning HTML instead of XML / JSON

September 9th, 2009
2 comments

I wasn’t going to write about this, but it’s been two weeks now, and more than a few people are agonizing over their Twitter API based apps not working. In case the title didn’t give it away, Twitter has been intermittently returning an empty HTML page as a response to API calls. I’m making XML requests, but the issue is also plaguing JSON requests. More about it here…

In an ideal world, a RESTful response should always be in the format requested. From what I’ve read, it appears this issue may be caused by recent measures to help prevent DoS attacks. Either way, I couldn’t wait any longer for Twitter to address the issue. Hopefully this helps someone else out…

My issues began when I first started building an application based on the twitter datasource. My Twitter data iterators kept throwing errors. By debugging the response before letting the datasource convert it into an array, I saw the request was retuning a 200 success header, and the following HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="0.1">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<TITLE></TITLE>
</HEAD>
<BODY><P></BODY>
</HTML>

Based on other user’s experience, it seemed waiting about .3 of a second usually cleared up the HTML response issue, and within 2-3 additional requests, you retrieved the data you were after. So I modified my _twitterReqest method, a simple wrapper for my calls to the datasource, to make the same request up to 5 times with a .3 second pause between requests until the data was returned in an acceptable format.

If 5 times wasn’t enough, I output a message explaining to the user that the API is unresponsive at the moment. So far, this message has yet to appear, and looking at my logs, I’ve never had to retry a request more than 2 times.

As soon as I get the data I want, I cache it for 24 hours, hopefully avoiding further issues for another day.

Here’s a quick look at my method:

function _twitterRequest($method = null, $params = null, $tries = 5, $delay = 300000){
    /*
     * This wrapper method is necessary b/c of issue documented here:
     * http://code.google.com/p/twitter-api/issues/detail?id=968
     * http://code.google.com/p/twitter-api/issues/detail?id=1014
     *
     * iterates through api calls with a .3 second delay to allow twitter responses to clear
     * has yet to fail
     */
    if($method):
        $try = 1;
        while($try <= $tries){
            $response = $this->Twitter->$method($params);
            if(isset($response['Hash']['error']) || isset($response['User']) || isset($response['Users'])){
                return $response;
            } else {
                $this->log($method . ': retry # ' . $try);
                usleep($delay);
                $try ++;
            }
        }
        return false;
    endif;
}

It’s frustrating to have to test against 1 + 1 equaling 2, but I guess it’s just the price of developing with 3rd party platforms… The moral here is always check your data against the data format you’re expecting. Don’t assume anything!

kettle server-side , ,

Trim down Twitter API responses with CakePHP’s Set::extract

September 9th, 2009
No comments

I’ve been working a lot with the Twitter API lately; it’s been a frustrating experience, especially after being spoiled by the substantially more robust Facebook platform. One issue of particular concern was the volume of data being returned per request.

I am caching the response data, and I found that retrieving a list of 100 followers was storing over 150KB of cached data. One popular Twitter user could then easily be accounting for well over 1MB of cache files. I only needed about 4 fields from the XML response. I also knew the cakePHP Set class was the answer; I just didn’t know which method. So after a lot of trial and error, I figured out how to cut the fat with Set::extract. I’m not sure if this is the most efficient solution; also not sure if my regular expression is efficient… never did take the time to learn regular expressions. But my cache files are now ~18k vs. the ~150k they used to be.

I’m using the Twitter datasource which transforms Twitter’s XML response into an array. This is necessary as Set::extract expects an array, not an XML object. Assuming a $followers array:

$followers = Set::extract($followers, 'Users.User.{n}.{(id|name|profile_image_url|screen_name)}');

The {n} wildcard will allow every numeric key within ['Users']['User'] to survive the extract.
The {(id|name|profile_image_url|screen_name)} keeps only the data that maps to those keys (id, name, profile_image_url and screen_name); therefore my $followers array is reduced to:

Array
(
    [0] => Array
        (
            [id] => XXXXXXXX
            [name] => XXXXXXXX
            [screen_name] => XXXXXXXX
            [profile_image_url] => XXXXXXXX
        )

    [1] => Array
        (
            [id] => XXXXXXXX
            [name] => XXXXXXXX
            [screen_name] => XXXXXXXX
            [profile_image_url] => XXXXXXXX
        )
}

There’s some initial processing overhead, but I’m sure that will be more than offset by iterating through a much lighter array in the various actions.

kettle server-side , , ,