Page MenuHomePhabricator

null/empty integer values cause a badinteger error with api.php
Open, Needs TriagePublicBUG REPORT

Description

Description:
I am using the Drafts extension with Mediawiki 1.35. Yes, it is an unmaintained extension but I believe the behavior can happen with any extension. This extension has the ability to save drafts through its "savedrafts" action. One of its attributes, "section", is an integer that can be null.

Mediawiki introduced parameter validation with 1.35. When the Drafts plugin passes an empty "section" value, the api.php response is:

{"error":{"code":"badinteger","info":"Invalid value \"\" for integer parameter \"section\".","*":"See https://website.com/wiki/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."}}

The badinteger error gets thrown in part by "includes/libs/ParamValidator/TypeDef/IntegerDef.php". The "section" value that was passed is empty (because it is null), but according to the regexp in IntegerDef.php:26 (link: https://doc.wikimedia.org/mediawiki-core/master/php/IntegerDef_8php_source.html ), it cannot be empty.

Shouldn't IntegerDef.php be allowed to accept empty values since some fields can be optional?

Steps to Reproduce:

  1. Install Mediawiki 1.35 and the latest Drafts extension, e.g. at: https://extdist.wmflabs.org/dist/extensions/Drafts-REL1_35-ff3bf06.tar.gz. Enable the plugin in LocalSettings.php by adding: wfLoadExtension( 'Drafts' );
  2. Login
  3. Create a new page and make an edit
  4. Attempt to save a draft. You will receive an error. If you use Chrome Developer tools, you will see the response from api.php with error text.

Actual Results:
When given an empty integer value, api.php gives a "badinteger" error.

Expected Results:
I expect empty integer values to be accepted by api.php

Other information:
Here is a sample curl request that contains the parameters used in the POST to api.php (some info redacted):

curl 'https://website.com/wiki/api.php'

--data-raw 'action=savedrafts&format=json&drafttoken=aaaaaaffe7e1768b3de3303c8405d3ed&id=0&title=MYwiki&section=&starttime=20210203011549&edittime=20210130090156&scrolltop=0&text=%3Cstrong%3EMYWiki%3C%2Fstrong%3E%0A%0AThe+purpose+of+this+Wiki+is+blah%0A&summary=&token=aaaaaa7b169b3d4870ac51ded0a58e6d6019f945%2B%5C'

Event Timeline

I think I "fixed" this for Drafts specifically in 28f48e343e675fc887ea2fe59025de7ce7d19208 by switching the default value from integer to null...which, indeed, more like hides the issue rather than truly fixes it, and obviously only in that extension.

(I should note that "the latest Drafts extension" in the "steps to reproduce" seems to have been "latest REL1_35 version of the extension" at the time this report was filed, as opposed to "latest master version of the extension", which would've included the aforementioned "fix". Of course usually running master version of an extension is not guaranteed to be compatible with the LTS version of MW core...)