It currently still works to POST to the API via http instead of https. But
we'd really like to stop allowing that, see
https://phabricator.wikimedia.org/T105794. Thus, the API will now return a
warning if https was expected but not used.
If you run a bot, please check your configuration to make sure that you're
using https rather than http. If you're using a distinctive user agent for
your bot (which you all are, right?[1]), you can now check whether your bot
is using http by going to
https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your agent
(or any useful prefix of it), and looking for "https-expected".
If for some reason your bot cannot support https, you really should upgrade
it to make that happen.
[1]: https://meta.wikimedia.org/wiki/User-Agent_policy
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
With the merge of Gerrit change 264309,[1] there are two changes to the
handling of login and createaccount tokens. The changes should be deployed
to WMF wikis with 1.27.0-wmf.12, see
https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap for the schedule.
Neither of these changes should break existing API clients, unless the
client is treating API warnings as errors or is doing something unusual
with these tokens.
The first change is that login and createaccount tokens now use the same
token generation mechanism as other CSRF tokens, but not the special case
that results in other CSRF tokens always being "+\" when not logged in.
This means that login and createaccount tokens will be longer, will end in
"+\", and include an embedded timestamp so a potential future change could
have them expire after a defined time period rather than lasting for the
duration of the session.
The second change is that login and createaccount tokens will now be able
to be fetched via action=query&meta=tokens, in the same manner as other
CSRF tokens. Fetching them by submitting an action=login or
action=createaccount request without a token (to receive a NeedToken
response) is now deprecated, and a warning will be returned along with the
NeedToken response indicating this deprecation. There is no plan to
actually remove the NeedToken response from action=login at this time, and
any future plan for its removal will be announced separately with
appropriate lead time. The NeedToken response will remain in
action=createaccount until the previously-announced breaking change to that
module,[2] and will be removed from action=createaccount along with that
breaking change.
[1]: https://gerrit.wikimedia.org/r/#/c/264309/
[2]:
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0…
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
You may remember the announcement last week about changes for bot login (if
you somehow missed it, see
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0…).
This is the promised follow-up for clients that do interactive login, and
also for anyone doing account creation.
AuthManager is going to be changing how some API modules work. For
interactive user login, you're going to want to change to using
action=clientlogin. The action=createaccount is also going to change to a
more interactive flow. The WIP code for the new API modules is in
https://gerrit.wikimedia.org/r/#/c/265201/; it's not too late to change
stuff in there, but bring good reasons.
Our target is to have this rolling out to WMF wikis by the end of February.
The general procedure for using both of these will be the same:
1. Fetch the initial field information from the new
action=query&meta=authmanagerinfo. Using format=json, the relevant part of
the data structure is an object with keys being field names and values
being objects that include the data type (string, password, select,
multiselect, checkbox, button), localized labels, and such.
2. Convert that field information into UI to display to your users.
3. Take the user input and post it to action=clientlogin or
action=createaccount, along with some other information documented in those
modules.
4. The response will tell you what to do next:
- PASS: You're done, it succeeded.
- FAIL: You're done, it failed. There's a localized "message" field
to tell you why.
- UI: More user input is needed. There's a localized "message", and
there's field information like you got in step 1. You'll repeat steps 2–4
with the new fields (and with slightly different module
parameters in step
3).
The use cases here include requesting the second factor for 2-factor
auth, prompting the user to reset their password, informing them
that they
were renamed from "Example" to "Example~enwiki", etc.
- REDIRECT: It wants you to send the user to another website, e.g.
pop up a browser or a web view. Once the remote site is done, it'll send
the user to a URL you specified in step 3, at which time you'll
extract the
data from that request and repeat steps 3–4. There's also provision for
skipping the redirect if your app knows how to do a non-web
authentication
against the provider, e.g. a GoogleLogin extension could provide
data that
an Android app needs to use some internal Android API to
authenticate with
a Google account and get the needed data.
The use case here is for something like "log in with Google", "log in
with Facebook", generic "log in with OpenID", and so on where you have to
send the user to some other site.
- RESTART: This means that the user authenticated ok, but we don't
know what user account the credentials belong to. You could treat this
response as if it were UI so they can log in with a different
mechanism, or
as FAIL, or you could start up action=createaccount to create a
new account.
The use case here is again something like "log in with Google",
Google returned success but we don't have any on-wiki account linked with
that Google account.
Account creation is going to break on day 1, we're not trying to maintain
any backwards compatibility there since it wouldn't be likely to work very
well anyway and there aren't many account creation clients out there.
The old login with action=login will probably continue to work for users
who don't have 2-factor auth, a migrated CentralAuth account (i.e. trying
to log in as Example when you're now Example~enwiki), or anything else that
would make a UI or REDIRECT response be returned, but again we're not
guaranteeing that it won't suddenly stop at some point. Also, the old login
mechanism will start returning a "Aborted" or "Failed" (with a localized
message) rather than "WrongToken", "BadPassword", "Throttled", and so on.
MediaWiki's authentication layer is getting a major overhaul. For more
details see the announcement "MediaWiki authentication changes" sent to
wikitech-l[1]; this email will repeat the portion relevant to bots. If you
maintain an interactive application that uses API login, the details of how
this will affect you aren't yet finalized; see the announcement on
wikitech-l for more, or wait for a future announcement to this list once
the details are available.
The "thinks will break" date has not yet been decided, but the goal is to
have it ready by the end of February.
*TL;DR:* Switch your bot to OAuth if possible, or look at
Special:BotPasswords (being deployed next week on WMF wikis) to set up a
new username+password for your bot to use with action=login in the future.
The new authentication features mean that unattended login might no longer
work since the login flow will now natively support user interaction: the
account might have 2-factor enabled, or might need a password reset, or
some other thing that requires user interaction. We've created two ways to
work around this:
- If possible, switch to OAuth. This week (1.27.0-wmf.10) "owner-only"
consumers are being rolled out to make this easier for bot operators: log
into your bot account, go to
https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose,
and create a consumer with the "This consumer is for use only by MyBotName"
checkbox checked.The consumer will be approved for use immediately, no
waiting or trying to find someone who can approve the consumer for you.
Owner-only consumers also don't tag every edit, since all the edits will be
from the one account anyway.
- If you need to continue using the existing action=login, next week
(1.27.0-wmf.11) we're rolling out Bot Passwords. This is something like
OAuth-lite, or Google's application passwords: go to Special:BotPasswords,
set one up, and then use new bot-password username and password to login as
you've always done (no code changes, just update your bot's configuration).
It's already live in Beta Labs if you want to test it out.
action=login with the "main" account password might still continue to work
after the new AuthManager is deployed, as long as nothing requires user
interaction.
For bots that run on third-party wikis, Bot Passwords are in core and are
enabled by default, but it's possible a wiki could disable them. OAuth is
an extension that the wiki may or may not have installed.
[1]:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-January/084501.html
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
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
Hi,
The format of the version of MediaWiki releases to Wikimedia sites is
changing with the 1.27 release cycle.
Old format: 1.26wmf24
New format: 1.27.0-wmf.1
This affects the "generator" property of action=query&meta=siteinfo.
This is being done to bring the version numbers in compliance with the
semantic versioning standard[1]. See the Phabricator ticket for more
details[2]. This switch will happen with the 1.27.0-wmf.1 deployment,
which started today, and will reach all sites on Thursday, October 1.
Frameworks (like Pywikibot) that check the version number for
compatibility checking may need to be updated for the new format.
Apologies for the late notice.
[1] http://semver.org/
[2] https://phabricator.wikimedia.org/T67306
-- Legoktm
Apologies to those seeing this twice, but it's important enough to announce
widely.
---------- Forwarded message ----------
From: Matthew Flaschen <mflaschen(a)wikimedia.org>
Date: Tue, Sep 29, 2015 at 4:05 PM
Subject: [Mediawiki-api] Tips for using bots and user scripts with Flow
To: mediawiki-api(a)lists.wikimedia.org, EE List <ee(a)lists.wikimedia.org>
Flow will start appearing more widely soon when we release a feature to
allow users on certain wikis to opt into Flow on their user talk pages.
The most common thing you'll probably want to do on a Flow page is post a
new topic.
For Pywikibot, that is pretty easy, since they have Flow support now. See
https://www.mediawiki.org/wiki/Manual:Pywikibot/Flow .
For on-wiki scripts, you can use MessagePoster (you don't need to know if
it's a Flow board ahead of time!):
---
var title = new mw.Title( 'titleString' );
var posterPromise = mw.messagePoster.factory.create( title );
posterPromise.done( function ( poster ) {
poster.post( 'This is the topic title', 'This is the body
of a message posted with MessagePoster' );
} );
---
Depend on 'mediawiki.messagePoster' and 'mediawiki.Title'.
In some cases, you might want to check if a link is already there (e.g. to
see if a warning template already included links to a particular policy).
You can use prop=links for this.
Flow is based on an infinitely-scrollable list of topics, each of which is
its own page. So to use prop=links, you may need to loop through a set of
recent enough topics (e.g. 25) then combine them into a prop=links request,
e.g.
https://www.mediawiki.org/w/api.php?action=query&titles=Topic:Sojpiv245cuiw…
.
pywikibot has support for looping through topics.
Some bots need to check the header of a page for wikitext (e.g. a bot
exclusion template). This can be done with view-header, but I don't think
pywikibot has support for that yet (but it can be done directly). See
https://www.mediawiki.org/w/api.php?action=flow&format=jsonfm&page=Talk%3AF…
.
A better way to do this would be templatelinks, but I'm not sure if there
is an API to show templates PageX transcludes.
For other questions, contact us at #wikimedia-collaboration . Or, if a
certain tool needs Flow support and you're not sure where to start, you can
file a bug (you can also reply here, but a ping in IRC would be
appreciated).
Matt Flaschen
Hi all!
We have some breaking API changes that will soon be deployed to wikidata.org.
The deployment date should be: 9th September 2015 (just under 2 weeks)
The change making the breaks an be found at:
https://gerrit.wikimedia.org/r/#/c/227686/
The breaking changes are:
- XML output aliases are now grouped by language
- XML output may no longer give elements when they are empty
- XML any claim, qualifier, reference or snak elements that had an
'_idx' element will no longer have it
- ALL output may now give empty elements, ie. labels when an entity has none
If you want to see a wikipage explaining these changes take a look at:
https://www.wikidata.org/wiki/User:Addshore/API_Break_September_2015
If you have any questions regarding these breaking changes please ask!
Addshore