API:Login/ru

API движка MediaWiki может требовать, чтобы ваше приложение или клиент предоставили данные для аутентификации пользователя в целях успешного выполнения операции. В MediaWiki 1.27 есть два API-действия, используемых для аутентификации:  и.

Боты и прочие неинтерактивные приложения, когда это возможно, должны использовать owner-only OAuth consumers для аутентификации, как более безопасный метод. Однако в действии  можно использовать и пароли для ботов, как описано ниже на этой странице.

Интерактивные приложения, такие как пользовательские редакторы или приложения для патрулирования, которые работают, не заменяя веб-сайт полностью, обычно также используют OAuth для аутентификации программы, т.к. это проще и безопаснее, однако  может быть использован, если это недоступно.

Интерактивные приложения, такие как мобильные приложения, которые стремятся полностью заменить веб-сайт, должны использовать  для аутентификации.

Как войти в учётную запись
Вашей программе потребуется авторизоваться MediaWiki, если:


 * ему нужно получить информацию или исполнить действие, разрешённое только участникам с определёнными правами
 * он выполняет большие запросы поиска, которые были бы неэффективны без использования доступным только привилегированным участникам бОльших пределов на количество результатов за запрос

На вики, разрешающих анонимное редактирование, возможно редактировать через API без входа в учётную запись, но это действие всё равно крайне рекомендуется выполнять. На приватных вики, вход необходим для использования любых API функций.

Если ваш клиент написан на исполняемом в браузере пользователя JavaScript, он обычно работает с учетными данными использующего его пользователя, и поэтому не требует авторизации сам по себе. В этом случае вам не потребуется входить в учётную запись через API сетевых служб: вам всего лишь потребуется убедиться, что пользователь вошёл в учётную запись через веб-интерфейс.

Если ваш клиент использует OAuth или подобный механизм, ему не нужно явно входить в учётную запись, так как все OAuth запросы автоматически аутентифицированы.

Учетные записи приложений
Если вы не хотите, чтобы ваше приложение входило в вашу учётную запись, вы можете создать отдельную учётную запись специально для вашего приложения. Это особенно важно, если ваше приложение:


 * выполняет автоматизированные правки или другие операции в большом количестве.
 * вызывает большие или ресурсозатратные информационные запросы.

При наличии отдельной учётной записи, изменения, произведённые вашим приложением, легко отследить, а к учётной записи приложения можно применить особые группы прав (обычно группу ботов). Некоторые вики устанавливают внутреннюю политику автоматического редактирования и/или процедуру обработки запросов присвоения прав бота.

Как проверить, авторизованы ли вы
Механизм логина обычно использует cookies, чтобы отслеживать статус сессии. Однако клиенты должны непосредственно проверять, залогинены ли они, а не пытаться определить это, проверяя cookies или логинясь вслепую, вне зависимости от того, требуется ли это.

Рекоммендованный способ убедиться, что запросы исполняются от вошедшего в систему клиента — использовать параметр assert=user, который принимается при любом API-вызове. При использовании этого параметра, если пользователь незалогинен, будет возвращена ошибка assertuserfailed.

Чтобы непосредственно проверить, под каким пользователем вы залогинены (и залогинены ли вообще), используйте модуль запросов.

Как войти в учётную запись
В MediaWiki до версии 1.27 присутствовало только действие, и все клиенты должны были пользоваться им. Начинай с версии 1.27, действие  должно использоваться только в комбинации с паролями ботов, а интерактивные приложения должны использовать.

Учтите, что процедура логина и поддержание статуса "залогинен" требует корректной обработки HTTP-cookies вашим клиентом при каждом запросе. Как правило, фреймворки и библиотеки для HTTP-запросов делают это за вас.

Действие
To successfully log in, a login token must first be retrieved. In MediaWiki 1.27 and later, this token should be fetched using a query with. For older versions, a POST to the  action is required instead.

Other fields might be included in the response, however these are deprecated and should be ignored if present.

Once the token has been fetched, the login may proceed.

Other fields might be included in the response, however these are deprecated and should be ignored if present.

The result field in the output indicates whether the login was successful. Non-successful results include:


 * NeedToken if the lgtoken parameter was not provided or no session was active (e.g. your cookie handling is broken).
 * WrongToken if the supplied token was not a valid token.
 * Failed (since 1.27) if the login failed. A reason field will exist in the response containing and explanation of the failure.
 * Aborted (since 1.27) if the login using the main account password (rather than a bot password) cannot proceed because user interaction is required. The  action should be used instead.
 * NoName (before 1.27) if no lgname was provided.
 * Illegal (before 1.27) if the lgname is not a valid user name.
 * NotExists (before 1.27) if supplied user does not exist.
 * EmptyPass (before 1.27) if the supplied password is empty.
 * WrongPass or WrongPluginPass (before 1.27) if the password is incorrect.
 * CreateBlocked (before 1.27) if auto-creation of the account is required but is not possible.
 * Throttled (before 1.27) if login attempts from your IP have been throttled.
 * Blocked (before 1.27) if the user being logged in to is blocked and blocks prevent login on the wiki.
 * Aborted (before 1.27) if the login was aborted by an extension without further detail. A reason field may be present.

Действие
This action implements an interactive login process, which might include CAPTCHAs, interactions with third-party authentication services, two-factor authentication, and more. As such, the specific fields required may vary depending on the configuration of the wiki. A description of the fields needed should be fetched from the query.

On a wiki without any special authentication extensions, the fields needed might include username, password , and optionally rememberMe , so the login request would look something like this:

On the other hand, a wiki with a CAPTCHA extension, an extension for authentication using OpenID Connect, and a two-factor authentication extension might have a more complicated authentication process.

The client would be expected to redirect the user's browser to the provided redirecttarget. The OpenID provider would authenticate, and redirect to Special:OpenIDConnectReturn on the wiki, which would validate the OpenID response and then redirect to the loginreturnurl provided in the first POST to the API with the code and state parameters added. The client gets control of the process back at this point and makes its next API request.

Now the client needs to ask the user to check their two-factor authentication app for the current code, and submit that back to the server to continue the authentication process.

The authentication process has finally succeeded.

If at any point authentication fails, a response with status FAIL will be returned, along with a message to display to the user.

In certain cases it's possible to receive a RESTART response, for example if the OpenID Connect extension had no mapping for the OpenID account to any local user. In this case the client might restart the login process from the beginning or might switch to account creation, in either case passing the loginpreservestate or createpreservestate parameter to preserve some state.