The Mediawiki oauth provider for Phabricator is functional and heavily used by Wikimedia developers on https://phabricator.wikimedia.org
You can download the source code from https://github.com/wikimedia/phabricator-extensions
It no longer seems necessary or particularly useful to have this live in the upstream.
Cool, sounds good to me.
You can check out D9004 and D9019 for recent changes which added an OAuth provider (in that case, Wordpress).
(The construction of a separate Future class in D9004 isn't really necessary, but will make it easier for Phabricator to make API calls later, if that's something you might want to do.)
Status: https://secure.phabricator.com/D9203 needs review; https://secure.phabricator.com/D9202 needs revision.
FYI: I'm still working on this. I've addressed all of the feedback in D9202 but now there is a bug somewhere.
Between the upstream changes in phabricator (which I rebased onto and adjusted as needed) combined with recent changes in mediawiki's OAuth implementation, something caused it to stop working. Now mediawiki doesn't get the consumer key with the request. I'm still debugging that issue and I'll submit updated differential revisions for D9202 and D9203 once everything is working (hopefully very soon)
@epriestley: This is now tested against mediawiki.org and both patches should be ready for review. I believe I have addressed all of your concerns and suggestions; everything should be good to go as soon as you have a chance to review.
What was the user in "Unknown Object (User) moved this task to Important on the Wikimedia workboard", https://secure.phabricator.com/T5096#78907?
If I recall correctly, a user that probably wanted to test a workboard and did so with ours, moving this task and a few others.
@epriestley: What do you think we should do, abandon the diffs or keep'em? If you don't want them it's ok, really! (also no rush to respond, this is no longer an urgent priority for me so don't spend too much time thinking about it, I know you're busy)
tldr;
status update on this:
I've cleaned up the code a bit further and moved it out of our downstream fork, and into our Phabricator/extensions repo instead - this is much cleaner since it avoids splitting the provider and the adapter between phab and libphutil. It also avoids rebasing the patch every time we upgrade phabricator.
If upstream is still interested in this I can make the effort to revise the patches and clean things up further. It doesn't seem like there is much demand though, and 3rd parties can always grab the provider classes from our extensions repo if they want to use mediawik with phab in the same way that we are.
Since we haven't seen any other interest in this in the meantime (although maybe you have?), keeping it external is probably best for us -- it's conceptually something that we're comfortable with, but it's conceivable that you're approximately the only install using it. We'd be open to bringing it upstream in the future if there's more widespread interest/use.
(We did eventually upstream phutil_hashes_are_identical() which might let you simplify the implementation very slightly.)
@epriestley: The main motivation was that we had been maintaining these as cherry-picked patches on top of phabricator core, which required constant rebasing. It was ridiculous and not even necessary. Eventually I figured out that phabricator doesn't care if the auth providers live in an external library. I sure wish I'd figured that out in the beginning, it would have made things a lot easier ;)
I'm actually embarrassed to admit that a lot of time was wasted on needless rebasing, but now I'm much happier with everything living in an extension, our phabricator "fork" is 99.9% vanilla. The only changes in our fork are the favicon.ico and robots.txt.
Aaah! That makes sense.
Adding New Classes in the docs got updated somewhat-recently-ish and is hopefully a little more clear about things now (although maybe it could still be better, it's not super explicit on this still).