For performance reasons,[1] when "miser mode" is enabled, as it is on WMF
wikis, queries to list=allpages using apfilterredir=redirects and
apfilterredir=nonredirects may begin returning fewer than the requested
aplimit results before continuation. In extreme cases, zero results may be
returned.
This change[2] has just been made and will be deployed in the next few
hours so Special:AllPages may be re-enabled.
This is not classified as a breaking change since the API has reserved the
right (since 2009[3] if not earlier) to do this sort of thing as it may
become necessary.
[1]: https://phabricator.wikimedia.org/T160916
[2]: https://gerrit.wikimedia.org/r/#/c/343681/
[3]: https://phabricator.wikimedia.org/rSVN46845
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
As was previously announced, passing the lgpassword or lgtoken parameters
to action=login in the query string rather than the POST body will begin to
return an error starting with 1.29.0-wmf.13. See
https://www.mediawiki.org/wiki/MediaWiki_1.29/Roadmap for the deployment
schedule.
On Mon, Oct 31, 2016 at 2:44 PM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org
> wrote:
> Over the past 30 days, there has been exactly one hit to
> action=clientlogin with sensitive data in the query string, and none to
> action=createaccount, action=linkaccount, and action=changeauthenticationdata.
> Beginning in 1.29.0-wmf.1 (to be deployed this week) these actions will now
> begin throwing errors if sensitive fields are included in the query string.
>
> Over the past 30 days, logins have been attempted via action=login for 28
> different user names[1] with sensitive data (lgpassword or lgtoken) in the
> query string. This will continue to work for now; my current plan is to
> turn that warning into an error on February 15, 2017.
>
>
> [1]: I can't post the list publicly at this time. If you want to know if
> you're one of the 28, put your user agent into https://meta.wikimedia.org/
> wiki/Special:ApiFeatureUsage and look for "login-params-in-query-string".
>
>
> On Fri, Aug 19, 2016 at 3:24 PM, Brad Jorsch (Anomie) <
> bjorsch(a)wikimedia.org> wrote:
>
>> 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
>>
>
>
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
To operate correctly, action=purge needs to write to the database, which
means it should be done using a POST rather than a GET request.
As of Gerrit change 310560,[1] action=purge will begin emitting a warning
when used via GET. This should be deployed to WMF wikis with 1.28.0-wmf.20,
see https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
Clients that use action=paraminfo to determine whether to use GET or POST
for an action should automatically switch to POST; any others should
manually switch to using POST for this action as soon as possible.
To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for 'purge-via-GET' once
1.28.0-wmf.20 is rolled out to wikis your client is using.
It is planned that this warning will be changed to an error 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/310560/
[2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
[3]: https://phabricator.wikimedia.org/T142155
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
With formatversion=1, boolean response fields are typically returned as the
empty string when true and are absent from the response when false. With
formatversion=2, boolean response fields in JSON and PHP formats are
supposed to be returned as native boolean true when true, and either native
boolean false or absent from the response when false.
Any boolean response fields that use the formatversion=1 semantics with
formatversion=2 should be fixed. Please file tasks in Phabricator if you
encounter such fields.[1] Clients using formatversion=2 should be prepared
for such response fields to be fixed without further warning.
[1]:
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tag=MediaWiki…
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
With the merge of Gerrit change 321406,[1] come some breaking changes to
the formatting of errors and warnings from some modules. These changes
should be on Beta Labs shortly, and should be deployed to WMF wikis with
1.29.0-wmf.6.
- Error codes returned by some modules have changed. Notably, codes from
query submodules will no longer include the module prefix, e.g. if you
supply a bad continuation parameter for prop=revisions it will report error
code 'badcontinue' instead of 'rvbadcontinue'. Other codes may have changed
as well, e.g. for list=allpages the error for attempting to use redirects=1
in generator mode is now 'invalidparammix' instead of 'params'.
- If you're attempting to parse the human-readable 'info' text of
errors, that text may have changed. Use cases should be submitted in
Phabricator[2] as feature requests to include the needed data in a
machine-readable format alongside the error message.
- action=emailuser may return a "Warnings" status, and now returns
'warnings' and 'errors' subelements (as applicable) instead of 'message'.
- action=imagerotate returns an 'errors' subelement rather than
'errormessage'.
- action=move now reports errors when moving the talk page as an array
under key 'talkmove-errors', rather than using 'talkmove-error-code' and
'talkmove-error-info'. The format for subpage move errors has also changed.
- action=rollback no longer returns a "messageHtml" property on errors.
Use errorformat=html if you're wanting HTML formatting of messages.
- action=upload now reports optional stash failures as an array under
key 'stasherrors' rather than a 'stashfailed' text string.
- action=watch reports 'errors' and 'warnings' instead of a single
'error'
This same change brings the ability to request errors and warnings in
languages other than English and formats other than plain text. See the new
'errorformat', 'errorlang', and 'errorsuselocal' parameters to the 'main'
module.
[1]: https://gerrit.wikimedia.org/r/#/c/321406/
[2]:
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tag=MediaWiki…
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
With the merge of Gerrit change 324224,[1] action=clearhasmsg will return
an error if used via GET rather than POST. The change should be deployed to
WMF wikis with 1.29.0-wmf.5, see https://www.mediawiki.org/
wiki/MediaWiki_1.29/Roadmap for the schedule.
This should have very low impact: analysis of logs indicates that only
Huggle[2] is using it, and Huggle has already been updated.
[1]: https://gerrit.wikimedia.org/r/#/c/324224/
[2]: https://en.wikipedia.org/wiki/Wikipedia:Huggle
--
Brad Jorsch (Anomie)
Senior 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
These response values, deprecated in December 2015, will no longer be
returned in the response to action=login. This change should be deployed to
WMF wikis with 1.28.0-wmf.13, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.
Note that the lgtoken *parameter* to action=login is not removed, nor is
the 'token' response value included along with a NeedToken response.
This is expected to have a low client impact, since proper handling of the
Set-Cookie headers (rather than manually building cookies using these
response values) has been effectively required for some time now.
The original deprecation announcement is quoted below:
On Tue, Dec 15, 2015 at 11:11 AM, Brad Jorsch (Anomie) <
bjorsch(a)wikimedia.org> wrote:
> Long ago, the only mechanism for session management in MediaWiki was
> certain cookies set by the User class. When ApiLogin was written, in
> addition to setting these cookies as usual it also returned some of the
> values needed to construct these cookies on the client. Presumably this was
> to make things easier for clients that somehow couldn't handle the standard
> cookie headers.
>
> Then CentralAuth came along. Now, constructing the cookies manually would
> log you in to the local wiki only, without taking advantage of the SUL
> mechanism.
>
> Then T55032[1] happened, and clients that were using the
> manual-construction mechanism had to update their code because one of the
> cookie names changed and that wasn't part of the data being returned.
>
> And soon, we'll have SessionManager and AuthManager, which will make it
> possible for login to easily happen in ways that don't involve cookies at
> all.
>
> So it's time to eliminate the pretense that clients can manually construct
> the cookies instead of handing the standard HTTP cookie headers. Tentative
> plan is to deprecate them now and then remove them sometime during 1.28; if
> anyone objects to this schedule, please raise your concerns in
> https://phabricator.wikimedia.org/T121527.
>
>
> [1]: https://phabricator.wikimedia.org/T55032
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation