API:Login/de

MediaWiki API kann von Deiner Applikation oder Deinem Client verlangen, authentifizierte Benutzer-Credentials für (a) Query-Informationen oder datenmodifizierende Aktionen (b) die große Queries mit höheren Request-per-Limits vorzuweisen.

Zwei Methoden für die Authentifizierung
Es gibt zwei Wege, um sich bei der MediaWiki action API zu athentifizieren:

Methode 1. Login
Bot and other non-interactive applications should use owner-only OAuth consumers if available as it is more secure. If not available or not applicable to the client, the  action may be used with bot passwords.

POST Request
Note: lgtoken in the request above is retrieved from API:Tokens

Sample code
login.py

Note: As of MediaWiki v1.27, using the main account for login is not supported. Obtain credentials via Special:BotPasswords or use  method. Logging in and remaining logged in requires correct HTTP cookie handling by your client on all requests. In the above example, we are showing how a session object helps persist cookies.

Method 2. clientlogin
Interactive applications such as custom editors or patrolling applications that provide a service without intending to fully replace the website or mobile apps that aim to completely replace access to the web-based user interface should use the  action. However, one should prefer using OAuth if it is available for authenticating the tool, as it is easier and more secure. This module is available since MediaWiki

POST Request
Obtain token login in the request above via API:Tokens.

Example 2: Process for a wiki with special authentication extensions
A wiki with special authentication extensions such as ConfirmEdit (captchas), OpenID, OATHAuth (two factor authentication), may have a more complicated authentication process. Specific fields might also be required in that case, the description of which could be fetched from the API:Authmanagerinfo query.

Step 1: Answer the Captcha and select OpenID authentication
Note: The client would be expected to redirect the user's browser to the provided. 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  and   parameters added. The client gets control of the process back at this point and makes its next API request.

Step 2: Back from OpenID
Note: 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.

Step 3: Two-factor authentication
Note: In certain cases it's possible to receive a  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.

Additional notes

 * On wikis that allow anonymous editing, it's possible to edit through the API without logging in, but it's highly recommended that you do log in. On private wikis, logging in is required to use any API functionality.
 * It is recommended to create a separate user account for your application. This is especially important if your application is carrying out automated editing or invoking large or performance-intensive queries. With that, it is easy to track changes made by the application and apply special rights to the application's account.