Let me explain the WMF use case a little more. We have lots of users create public tasks, often with pictures attached, which should be private (security/privacy issues, legal issues, etc). We push notifications of new tasks to our public irc channels, and a lot of our users subscribe to huge numbers of projects. So once the task is created, the content is widely dispersed. And we need the ability to make that as private as possible.

In D9202#54, @csteipp wrote:

The other option is to refactor the phutil OAuth class to allow passing in extra, non-url parameters to be signed. That would simplify the Jira plugin, since they also have to work around that.

In D9202#53, @20after4 wrote:

@csteipp, @WikiChad: I thought the getAuthorizeTokenURI had to usee /wiki/ instead of /w/index.php?

In D9202#48, @WikiChad wrote:

In D9202#47, @20after4 wrote:

The /w/ and /wiki/ urls are the default and recommended mediawiki configuration:

https://www.mediawiki.org/wiki/Manual:Short_URL

One issue is that the plugin only works with mediawiki.org when it uses /w/ and /wiki/ in appropriate places. I'm not sure how to make that part configurable without making it sorta confusing...

@csteipp can you offer any suggestions here?

I think it's pretty easy actually. Don't use /wiki/ and assume the wiki never has short URLs (which they very well might not). We don't have to use them. Then include /w/ in the base part of the URI you configure and you're set.

In D9202#14, @20after4 wrote:

In D9202#13, @csteipp wrote:

That's what the Twitter authentication does, but then they (break OAuth spec and) don't sign the request for the Access token with the secret from the Request token.

MediaWiki needs the secret from the first token to sign the request for the second token. We could try to encrypt it and pass it through as state in the authorization call, but it would be much easier (on me) if the client could keep track of it.

Or... if phabricator could keep it somewhere so that the client doesn't have to. I'd prefer that over encrypting it and sending it to the client as a cookie. The cookie seems really likely to fail, but maybe I'm just jaded from having many bad experiences with setcookie() in the past.

In D9202#12, @epriestley wrote:

After some thought, I realize we should actually already be handling this. Specifically, we set a client ID cookie (phcid) and then verify it by appending it to the callback URI (in PhabricatorAuthProviderOAuth1->processLoginRequest()). So it should be safe to just delete the cookie.

In D9203#7, @20after4 wrote:

In D9203#6, @epriestley wrote:

Is this stuff bound to WMF, or can I theoretically auth against any local install of Mediawiki? I've been assuming the latter, but maybe that's not true?

I think it should be able to auth against any mediawiki, with a bit of generalization. I wish I could pin down the original author of this bit of code but he doesn't have an account on secure.phabricator.com, Hopefully he will rectify that problem and join in the discussion here.