(We can switch to german, if anyone prefers)
Silvio and his co-workers put some effort into the Twitter plugin (serendipity_plugin_twitter / serendipity_event_twitter) to make it compatible with 0Auth. This is a major change in how Twitter handles authentication to post tweets.
On their blog, they offered this update:
http://www.webmaster-tagebuch.de/2010/0 ... erung.html
which I turned into this:
http://dl.dropbox.com/u/1444910/serendi ... witter.tgz
This uses some basic OAuth code, but did a few things that needed changes. Especially the way how the consumer/token keys are saved in files (instead of the s9y database) and to make calls to the serendipity external_plugin hook instead of calling .php files directly (which would be a security-relevant issue).
I today tried to integrate my suggestions into the plugin, but soon got aware that it's hard to read the code when I've never worked with Twitter OAuth before.
I believe I properly exchanged all the code calls to storage files to a unified database storage, and also changed all code calls to be routed through external_plugin (i.e. /blog/index.php?/plugin/twitteroa_redirect).
One major problem of mine is that I do not understand how to properly "connect" the plugin on your blog with your twitter account. From what I figure, the plugin does this:
When first configuring the plugin, no consumer_key and consumer_secret is set, and also no oauth_token and oauth_token_secret. To do so, you must register the App with Twitter, and a callback URL is provided that you need to enter in twitter (now: /blog/index.php?/plugin/twitteroa_callback).
The twitter target page is: https://twitter.com/apps/new -- and that page looks so convoluted and hard to understand, that I wouldn't want any serendipity user to need to understand each field there. There must be some kind of "Challenge-Response" link, so that Serendipity users can click a link, and everything is handled through the API so that they only need to tell Twitter.com "Yes, I want this application to use my credentials", right?
Inside the plugin, everything's that's related to Twitter OAuth is in these lines:
1. Plugin introspection on line 348:
Code: Select all
case 'twitteroa_consumer_key':
$this->handleConfig('twitteroa_consumer_key', $propbag);
break;
case 'twitteroa_consumer_secret':
$this->handleConfig('twitteroa_consumer_secret', $propbag);
break;
case 'twitteroa_sign_in':
$this->handleConfig('twitteroa_sign_in', $propbag);
break;
handleConfig is declared in line 170, and really only reads the database stored values, see if they exist, and depending on that return the configuration values.
The callback etc. handlers and routines can be found in lines 780 - 906. Those are mostly copies of the former .php files in Silvio's plugin variant. I only exchanged that keys/secrets are read from the database instead of stored files.
The actual OAuth confirmation/token responses are routed through here, so that's the heart of the authentication scheme that I don't properly get.
Calling the Twitter API is simply done like on line 1471:
Code: Select all
$connection = $this->twitteroa_connect();
/* statuses/update */
$parameters = array('status' => $update);
$status = $connection->post('statuses/update', $parameters);
Who's willing to take a dive and explain to me how the original OAuth token setup should take place?
Help is much appreciated.
Regards,
Garvin
Afaik it's not possible to pass parameters to that form. It's probably best to assemble all the necessary URLs and stuff in S9y and present them to the user on the plugin page, like this
