[dokuwiki] Re: OAuth plugin & auth.php patch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Gohr wrote:
> Hi,
> 
>> I ventured out to write an http://oauth.net/ plugin for dokuwiki: A user
>> authorizes an oAuth-token[..], which can later be used by a consumer to
>> perform requests on behalf of the user.
>>
>> see http://mir.dnsalias.com/wiki/dokuoauth for details, source and examples.
> 
> This looks great. Unfortunately I'm not familiar enough with how oauth
> works to say anything about the code yet.

The user-experience is similar to openID. Coder's experience as well ;)
This is how it can work:
http://www.hueniverse.com/hueniverse/2007/10/beginners-gui-1.html

In the next days I'll add a dokuwiki plugin to make signed requests so
that one can play without using 3rd party apps/sites.

Code wise the DBA database is the bottleneck. It came with the oauth-php
example and is good enough to get started. It also stores the tokens in
a *text* file (though somewhat cryptic). - using sqlite would make many
things easier, cleaner and reduce code size as well, we'll see.

>> In it's current state it implements an OAuth service-provider, the oAuth
>> plugin authenticates HTTP-GET, -POST and XML-RPC(!) requests to dokuwiki
>> according to oAuth Core 1.0 spec against a dokuwiki auth-backend. What's
>> missing is a nicer user/admin interface and integration with dokuwiki.
> 
> Can you elaborate a bit what this should look like and what user
> interfaces are needed?

One should be able to List, Revoke and Delete Access-tokens,
as well as Add Consumers ("enter": set by hand, "request": autogenerate,
"discover": XRDS) and Remove Consumers (usually an admin task).

Most of the admin-pages and callbacks are already in place; it's
basically helper.php that needs to be rewritten: add CSS, get rid of the
<table>, add $lang[], print "none available" instead of just nothing
etc.  Also the current buttons are for testing and are not according to
any user-interaction design..

The user-interaction to administrate "consumer/tokens used for
outgoing-requests" will be the same as the one for "consumer/tokens used
to access the current site". Only the text and buttons labels are different.

Have a look at http://oauth-sandbox.mediamatic.nl/module/OAuth

>> To hook into dokuwiki authentication on a per request basis a new
>> Doku_Event 'ACTION_ON_AUTH' has been introduced to ''inc/auth.php''.
>>
>> I pragmatically helped myself with a small patch, but would appreciate
>> information, if the same can be achieved without modifying dokuwiki or
>> if the attached diff can be merged into dokuwiki-devel.
> 
> I was prepared to say that this could be done with a custom auth
> backend but then saw on your documentation page that you considered
> this already. I think I can follow your argumentation and if nobody
> disagrees I'd add your event.
> 
>> Implementing an oAuth Consumer (sign outgoing requests - eg. {{rss>}}
>> extern-includes or picture-aggregation,..) seems to be limited to
>> specific plugins.  To implement this properly, dokuwiki would need to
>> add a dedicated function for outgoing HTTP requests that can be hooked
>> into. What do you think? Does that seem to be a reasonable
>> feature-request for later dokuwiki versions?
> 
> DokuWiki already has it's own HTTP client library that is used for all
> outgoing HTTP requests. Check the HTTPClient.php file. What would be
> needed to add oauth support there and what could one do with it?

Ideally there'd be an Event generated just before each HTTP request:
"HTTP_REQUEST_PREPARE" - One (or more) plugins can hook into this Event
and can apply for signing it. In a second iteration (advise_after()) the
request is signed (some URL query/post parameters are added) by the
winning plugin (via calling an oAuth-plugin function).

This way an oauthfeed-plugin could aggregate private feeds (eg from
twitter, jaiku,..) by using tokens from the user who last modified the
wiki page or using fixed tokens for a feed,..
pingbacks can be signed with a server-keys or the by the currently
logged-on user, etc.

Plugins that initiate a request themselves are easier: eg. a PubSub
plugin can sign the changeset before publishing it and already push a
signed-request to the HTTPClient.

Above Event would also open the doors to smart-caching. Combined with a
2nd event "HTTP_REQUEST_DONE" some plugin can catch 301s or 404's and
intervene the next time it sees the URL on a "HTTP_REQUEST_PREPARE".
HTTP connections take a very long time compared to calling Event hooks..

enough Events, I'm back to oAuth ;)
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkApiEACgkQeVUk8U+VK0JUKQCfYPCBWeH/HFUPXZrRv8z5MMG9
JNUAnRvXjPwXeledDEB3NJOt/9N7FG3t
=2Ul5
-----END PGP SIGNATURE-----
-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: