[OH-Dev] OpenHatch wiki now should work properly with MW API (also: a request for PHP coding)

[Asheesh Laroia]

Hey all,

There seemed to be a bug in the MediaWiki Django auth we're using. Having 
just worked around that bug, you can now use the MediaWiki API to log into 
the wiki.

(The code for the Django auth we're using is here: 
https://bitbucket.org/pythonian4000/django-mediawiki-authentication-by-user-id/ 
)

I talked it through with Mark Holmquist, with whom I figured out the 
underlying issue. (Thanks go to Mark for trying some things, reading the 
traces, and reading some code!)

Being able to log into the wiki means that I can use git-remote-mediawiki 
to delete spam via git, which is a notion that thrills me.

Details
-------

The bug was:

If you were successfully logged into the wiki via a username/password pair 
(meaning, skipping the Django authentication integration), our Django 
authentication plugin would aggressively log you out.

The reason it did that is subtle. It wants to support "central logout", 
with the following flow.

1. User logs into OpenHatch Django site (gains cookie called "sessionid")

2. User visits OpenHatch wiki (wiki notices Django sessionid cookie, looks 
up the user, and sets an OpenHatch wiki session ID cookie)

3. User visits openhatch.org/ and logs out, thereby removing the old 
"sessionid" cookie

4. User visits openhatch.org/wiki/ and the wiki notices that the Django 
cookie is gone, so the user should also be logged out of the wiki; it 
makes that the case by calling session_destroy() within MediaWiki.

Workaround
----------

What I did was comment out both calls to session_destroy(). It means I've 
created a new kind of buggy behavior: if you log out of the main OpenHatch 
site, you don't get auto-logged-out of the wiki.

Proper fix
----------

The way I see it, the right fix is to change the plugin's behavior so that 
if you were initially logged in via Django, and then you arrive without a 
Django cookie, you get logged out.

The best way I can think that the plugin can detect if the current session 
is one that was initiated through Django is for the plugin to set a 
special cookie in the browser called e.g. "wiki_auth_came_from_django" and 
set it to "1" or some other true-looking value. (Or, I realize now, the 
plugin could store this value in the server-side MediaWiki session, if 
it's easy to store data there.) Then, if that state exists, but a Django 
'sessionid' cookie does not, the plugin should call session_destroy().

Conclusion
----------

With that all said, I just had a good time deleting dozens of spam pages 
via git-remote-mediawiki. It's as easy as "git rm"-ing the pages I don't 
like, and doing "git push". You can see that here: 
https://openhatch.org/wiki/Special:RecentChanges

Quibbles worth mentioning:

* pull and push are both hilariously slow

* You have to use Roan's version of git-remote-mediawiki, as I mentioned 
in my previous emails to the list.

* In order to be able to do authenticated actions through the API, you 
have to configure a special MediaWiki-specific password via logging in and 
going into your wiki user preferences. This isn't hard, but it's worth 
mentioning since it's a required step.

I'll be pretty swamped the next few days, but if someone wants to fix up 
that MediaWiki extension, that would rule....

Again, here's the source: 
https://bitbucket.org/pythonian4000/django-mediawiki-authentication-by-user-id/

-- Asheesh.

P.S. Roan and Mark, yes, this means you can stop attempting to debug 
things via the API call transcripts I sent you....