update oauth_api plugin to include storage classes

[cash]

The source of the OAuth lib was hacked to use a function elggconnect_get_oauth_store() that does not exist.

We need to update the lib and decide whether we want to provide a server storage solution that uses metadata or instructions on creating additional tables for a custom MySQL implementation.

[kevinjardine]

The same problem exists for the client API, so I revised the title.

[kevinjardine]

As I need this immediately, I am working on a new "oauth" plugin that registers an "elgg:oauth" library and contains the latest unhacked oauth-php code from the Google repository.

As Cash suggests on the community site, I am creating a new Elgg store class that uses metadata rather than new tables.

[cash]

I just checked the twitter_api plugin which uses this OAuth library. The reason the client works there is that the twitter_api plugin caches the token in the session. The default client code in the oAuth lib must persist the token in the db.

[kevinjardine]

Cash, I think that the twitter_api plugin uses a completely different library.
I encountered the elggconnect_get_oauth_store() problem when I was testing the oauth_api plugin with a session store.

elggconnect_get_oauth_store() is scattered all over that code and hardly anything works unless it is replaced with the original OAuthStore::instance() calls.

[brettp]

Definitely didn't realize the lib file had been hacked. Absolutely agree to supply the actual oauth library instead. I don't think this is something we'd be able to squeeze in for 1.8.1 since we need to test/fix Twitter also, so setting to 1.8.2.

[kevinjardine]

It turned out that updating to the latest library and setting up the plugin with elgg_register_library was a trivial exercise. I have an OAuthElggStore class that currently is just a variation of the OAuthStureSession class except that it actually writes to the OAuth log (to the PHP error log). By the time I upload it to github tomorrow I imagine that it will also save access tokens per user.

I'll tell you when it is ready to look at.

[kevinjardine]

That should have been

"I have an OAuthStoreElgg class that currently is just a variation of the OAuthStoreSession class"

[kevinjardine]

Preliminary new oauth plugin up here:

​https://github.com/kevinjardine/OAuth-plugins

[kevinjardine]

Replying to kevinjardine:

Cash, I think that the twitter_api plugin uses a completely different library.
I encountered the elggconnect_get_oauth_store() problem when I was testing the oauth_api plugin with a session store.

elggconnect_get_oauth_store() is scattered all over that code and hardly anything works unless it is replaced with the original OAuthStore::instance() calls.

Correction - the twitter_api plugin does indeed use the oauth_api signature functions (which do not require any store).

[cash]

Moving this back to 1.8.3 - requires some discussion and planning.

[kevinjardine]

Just to note about a year later that I am no longer convinced of the usefulness of a generic OAuth library. The major web APIs are all over the map. Google and Facebook now use variations of OAuth 2.0 and Twitter is still at this moment using the very different OAuth 1.0a. There does not seem to be an easy to use library that combines all OAuth flavours. I've also noticed that Google in particular uses "xoauth" extensions that Twitter overtly rejects.

Each of these platforms do have there own SDKs, so it might make more sense to have separate Google/Twitter/Facebook library plugins.