When list=allusers is used with auactiveusers, a property 'recenteditcount'
is returned in the result. In bug 67301[1] it was pointed out that this
property is including various other logged actions, and so should really be
named something like "recentactions".
Gerrit change 130093,[2] merged today, adds the "recentactions" result
property. "recenteditcount" is also returned for backwards compatability,
but will be removed at some point during the MediaWiki 1.25 development
cycle.
Any clients using this property should be updated to use the new property
name. The new property will be available on WMF wikis with 1.24wmf12, see
https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap for the schedule.
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=67301
[2]: https://gerrit.wikimedia.org/r/#/c/130093/
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
For improved safety, passwords and other sensitive fields for
authentication should not be included in the request URI during a POST.
Instead, they should be in the POST body where they are less likely to be
included in log files. With the merge of Gerrit change 305545,[1] the API
will now produce a warning if such fields are detected in the URI. This
should be deployed to WMF wikis with 1.28.0-wmf.16, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
This affects the following modules and fields:
* action=login: 'lgpassword'
* action=clientlogin, action=createaccount, action=linkaccount, and
action=changeauthenticationdata: Any fields reported as "sensitive" by
action=query&meta=authmanagerinfo or by UI or REDIRECT responses.
Currently, this affects the 'password' and 'retype' fields.
The 'lgtoken' field for action=login will now also issue a warning if
placed in the request URI. The error code for other tokens being in the
request URI has changed from 'mustposttoken' to 'mustpostparams'.
To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for
'<action>-params-in-query-string' once 1.28.0-wmf.16 is rolled out to wikis
your client is logging in to.
It is planned that these warnings will be changed to errors during 1.29.
Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
waiting until it breaks. Thanks.
[1]: https://gerrit.wikimedia.org/r/#/c/305545/
[2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
[3]: https://phabricator.wikimedia.org/T142155
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Both of these changes should be deployed to WMF wikis with 1.28.0-wmf.17,
see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
== Alternative multi-value separator ==
With the merging of Gerrit change 305126,[1] if a value for a multi-valued
parameter must contain pipe characters (U+007C, "|"), it will now be
possible to use the Unit Separator character (U+001F) instead. As this
character is not otherwise valid input for any strings in MediaWiki, its
use here should not conflict with any valid input. To signal that you're
using this feature, the whole multi-value parameter must also be prefixed
with the Unit Separator character.
For example, you can now use meta=allmessages to parse the
"search-rewritten" message with the text "foo|bar" as $1 and "foo|baz" as
$2:
https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&meta=allmessag…
<https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&meta=allmessag…>
Client libraries should consider updating to use this feature when asked to
send a multi-valued parameter with one or more values containing pipe
characters.
== Unicode normalization warnings ==
The API has always expected input as NFC-normalized Unicode represented as
UTF-8. Non-NFC-normalized UTF-8 input would be silently normalized, and in
the query string non-UTF-8 input would be interpreted as being in a
fallback encoding (such as Windows-1252) and converted to Unicode. This
sometimes led to subtle bugs when input was unexpectedly converted.
With the merging of Gerrit change 306491,[2] the API will now issue a
warning when input was subject to such conversion, which is hoped to make
it more obvious to clients when their input was subject to conversion.
When this happens in the 'titles' parameter for ApiPageSet-using modules,
the response will also include the conversion of each title in the existing
'normalized' element. Since the API result cannot directly represent
non-normalized data, these entries will have the 'from' element
percent-encoded and a 'fromencoded' boolean will be included alongside to
indicate this. This normalization step is separate from the existing Title
normalization (uppercasing the first letter and replacing underscores with
spaces), so two entries may be generated in the 'normalized' element.
See
https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&titles=a%CC%8A…
for an example showing the new warning and normalization entries.
[1]: https://gerrit.wikimedia.org/r/#/c/305126/
[2]: https://gerrit.wikimedia.org/r/#/c/306491/
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hello, REST API users.
We are planning to deploy a new REST API endpoint for section editing next
week. This will replace the current /transform/sections/to/wikitext/
<https://en.wikipedia.org/api/rest_v1/#!/Transforms/post_transform_sections_…>
end point, and will provide the same functionality in a more streamlined
and extensible format.
The existing end point is classified as unstable
<https://www.mediawiki.org/wiki/API_versioning#Unstable>, which guarantees
that we are making an effort to avoid breaking existing clients. According
to our data, the end point is basically unused at present, which is why we
are aiming at a fairly speedy deploy around Tuesday next week (Aug 30). If
you are using this end point at present & have concerns about its removal,
then let us know here.
Best regards,
the WMF Services Team <https://www.mediawiki.org/wiki/Wikimedia_Services>.
--
Gabriel Wicke
Principal Engineer, Wikimedia Foundation