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-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce