{"id":978,"date":"2019-09-22T08:44:59","date_gmt":"2019-09-22T06:44:59","guid":{"rendered":"https:\/\/blogs.gentoo.org\/mgorny\/?p=978"},"modified":"2019-09-22T09:37:22","modified_gmt":"2019-09-22T07:37:22","slug":"the-gruesome-mediawiki-api","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2019\/09\/22\/the-gruesome-mediawiki-api\/","title":{"rendered":"The\u00a0gruesome MediaWiki API"},"content":{"rendered":"

I have recently needed to work with MediaWiki API. I wanted to create a trivial script to update UID\/GID assignment table<\/a> from its text counterpart. Sounds trivial? Well, it was not, as update-wiki-table<\/a> script proves.<\/p>\n

MediaWiki API really feels like someone took the webpage and replaced HTML templates with JSON, preserving all the silly aspects that do not make any sense. In this short article, I would like to summarize my experience by pointing out what is wrong with it, why and how it could be done much better.<\/p>\n

<\/p>\n

How many requests does it take?<\/h2>\n

How many API requests does it take to change a Project page? None because you can’t grant your bot password permissions to do that. Sadly, that’s not a joke but the reality in Gentoo Wiki. Surely it is our fault for not configuring it properly \u2014 or maybe upstream’s for making that configuration so hard? Nevertheless, the actual table had to be moved to public space to resolve that.<\/p>\n

Now, seriously, how many requests? I would have thought: maybe two. Actually, it’s four. Five, if you want to be nice. That is, in order:<\/p>\n

    \n
  1. request login token,<\/li>\n
  2. log in using the login token,<\/li>\n
  3. request CSRF token,<\/li>\n
  4. update the page using CSRF token,<\/li>\n
  5. log out.<\/li>\n<\/ol>\n

    Good news: you don’t need to fetch yet another token to log out. You can use the same CSRF token you used to edit the Wiki page!<\/p>\n

    Now, what’s the deal with all those tokens? CSRF<\/abbr> attacks are a danger to people using a web browser! How would you issue a CSRF attack against an API client if the client has pretty clearly defined what it’s supposed to do? Really, requesting extra tokens is just busywork that makes the API unpleasant and slow.<\/p>\n

    So, the bare minimum: remove those useless tokens, and get down to three requests. Ideally, since I only care to perform a single action, the API would let me provide credentials along with it without the login-logout ping-pong. This would get it down to one request.<\/p>\n

    Cookies, sir?<\/h2>\n

    The Python examples in MediaWiki documentation use requests<\/a> module (e.g. API:Edit example<\/a>). Since I don’t like extraneous external dependencies, I’ve initially rewritten it to use the built-in urllib<\/a>. That was a mistake, and a badly documented one.<\/p>\n

    I’ve gotten as far as to the login request. However, it repeatedly claimed that I’m implicitly requesting a login token (which is deprecated) and gave me a new one rather than actually logging me in. Except that I did pass the login token!<\/p>\n

    It turned out that everything hinges on\u2026 cookies. Sure, it’s my fault for not reading the API documentation thoroughly. It is upstream’s fault for making a really silly API that requires a deep browser emulation to work, and for providing horribly misguided error messages.<\/p>\n

    Why should an API use cookies in the first place? You don’t need to pass data behind my back! Since I am writing the API client, I am more than happy to pass whatever data needs to be passed explicitly, in API requests. After all, you require me to pass lots of tokens explicitly anyway, so why not actually make them do something useful?!<\/p>\n

    Bot passwords, bot usernames<\/h2>\n

    Now, MediaWiki prohibits you from using your account credentials to log in, without engaging in ever bigger hoops. Of course, that makes sense \u2014 I neither want my password stored somewhere script-accessible, nor give the script full admin powers. Instead, I am supposed to obtain a bot password<\/a> and grant it specific permissions. Feels like typical case of an API key? Well, it’s not.<\/p>\n

    Not only I do need to explicitly pass username with the autogenerated bot password but I need to pass a special bot username. This is just plain silly. Since bot passwords are autogenerated, it should be trivially possible to enforce their uniqueness and infer the correct bot account from that. There is no technical reason to require username\/password pair for bot login, and it just adds complexity for no benefit.<\/p>\n

    I am actively using both Bugzilla and GitHub APIs. Both work fine with a simple API token that I keep stored in an unstructured text file. Now I’m being picky but why has MediaWiki to be a special snowflake here?<\/p>\n

    Summary, or the ideal API<\/h2>\n

    How should the MediaWiki API look like, if done properly? For a start, it would be freed of all its~useless complexity. Instead of bot username\/password pair, just a single unique API key. No login tokens, no CSRF tokens, no cookies! Just issue a login request with your API key, get a session key in return and pass it to other requests. Or even better \u2014 just pass the API key directly to all the requests, so simple one-shot actions such as edits would actually take one request.<\/p>\n","protected":false},"excerpt":{"rendered":"

    I have recently needed to work with MediaWiki API. I wanted to create a trivial script to update UID\/GID assignment table from its text counterpart. Sounds trivial? Well, it was not, as update-wiki-table script proves. MediaWiki API really feels like someone took the webpage and replaced HTML templates with JSON, preserving all the silly aspects that do not make any sense. In this short article, I would like to summarize my … Continue reading “The\u00a0gruesome MediaWiki API”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[9],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/978"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=978"}],"version-history":[{"count":18,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/978\/revisions"}],"predecessor-version":[{"id":996,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/978\/revisions\/996"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=978"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=978"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=978"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}