I personally use Zend Oauth for connecting my application to Twitter as referred to here: http://framework.zend.com/manual/en/zend.oauth.introduction.html

It really works perfectly saving the Twitter Request Token and also the Twitter Access Token within the session using serialize and unserialize such as this (abbreviated):

1: $consumer = new Zend_Oauth_Consumer($config);
2: $token = $consumer->getRequestToken();
3: $_SESSION['TWITTER_REQUEST_TOKEN'] = serialize($token); //write Request Token


4: $consumer = new Zend_Oauth_Consumer($config);
5: $token = $consumer->getAccessToken($_GET,
6: $_SESSION['TWITTER_ACCESS_TOKEN'] = serialize($token); //write Access Token


7: $token = unserialize($_SESSION['TWITTER_ACCESS_TOKEN']);
8: $client = $token->getHttpClient($configuration);

Now I wish to save the Access Token during my mySQL database after line 6. However , the moment I actually do this the entry within the db consists of strange figures such as this:


which results in a notice (Error at offset 30 of 280 bytes) in line 7 and and fatal error online 8 because $token is really a non-object. And So I attempted to determine the mistake and already published the issue in the Zend forum but nobody may help me... My best guess is the fact that this is an encoding error. The database and all sorts of my documents are encoded corretly in utf-8 though and that i didn't have problems such as this before... A var_dump($token) in line 3 shows me that you will find already crytpic chars there. Here's an extract:

"Accept-Encoding" ["Content-encoding"]=>  string(4) "gzip" ["Content-length"]=>  string(3) "146" ["Connection"]=>  string(5) "close" } ["body":protected]=>  string(146) "�������E˹� ��п��J;80���4(,9��� ��.M��ؖ�"K���H���Q��a|;W����d2��.�׸Je�-���-y.���3��〺  object(Zend_Oauth_Http_Utility)#89 (0)

May be the content-encoding gzip the issue? Or perhaps is the issue triggered by Zend and also the getRequestToken() method? Any assistance is highly appreciated. Thanks ahead of time

Obtained from the php.internet help on serialize

wired caracters are added while serialisation for protected and vars, it is a null byte

If serializing objects to become saved right into a postgresql database, the 'null byte' injected web hosting and guarded people throws a wrench in to the system. Even pg_escape_bytea() around the value, and storing the worthiness like a binary type fails under certain conditions.

For any dirty deal with:

$serialized_object = serialize($my_object) $safe_object = str_replace("", "~~NULL_BYTE~~", $serialized_object)


this enables you to definitely keep object inside a readable text format too. When reading through the information back:

$serialized_object = str_replace("~~NULL_BYTE~~", "", $safe_object) $my_object = unserialize($serialized_object)


The only real gotcha's with this particular technique is in case your object member names or values may in some way retain the odd "~~NULL_BYTE~~" string. If that's the situation, then str_replace() to some string that you're guaranteed not have anywhere else within the string that serialize() returns. Keep in mind to define the course before calling unserialize().

If you're storing session data right into a postgresql database, than the workaround is mandatory, since the $data passed towards the session's write function has already been serialized.