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- und andere nichtinteraktive Applikationen sollten wenn verfügbar owner-only OAuth consumers verwenden, weil das sicherer ist. Wenn nicht verfügbar oder mit dem Client nicht anwendbar, kann die -Action mit Botpasswörtern verwendet werden.

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: Vom Client wird erwartet, den Browser des Benutzers zum bereitgestellten  weiterzuleiten. Der OpenID-Anbieter sollte authentifizieren und zu Special:OpenIDConnectReturn im Wiki weiterleiten, was die OpenID-Antwort validieren würde und dann weiterleiten zur loginreturnurl, die im ersten POST an die API bereitgestellt wurde, mit angehängten - und  -Parametern. Der Client erhält an diesem Punkt die Konktrolle über den Prozess zurück und macht seine nächste API-Anfrage.

Step 2: Back from OpenID
Note: Nun muss der Client die Benutzer bitten, ihre Zwei-Faktor-Authentifizierungs-App für den aktuellen Code zu prüfen und dies zurück an den Server zu übermitteln, um den Authentifizierungsprozess fortzusetzen.

Step 3: Two-factor authentication
Beachte: In bestimmten Fällen ist es möglich, eine -Antwort zu erhalten, zum Beispiel, wenn die OpenID Connect-Erweiterung kein Mappung für den OpenID-Account eines lokalen Benutzers findet. In diesem Fall kann der Client dien Loginprozess ganz von vorn neustarten oder zur Accounterstellung wechseln wollen. In beiden Fällen gibt er den loginpreservestate - oder den createpreservestate -Parameter mit, um einige Status zu erhalten.

Zusätzliche Anmerkungen

 * In Wikis, die anonymes Bearbeiten erlauben ist möglich, mit der API zu bearbeiten, ohne sich einzuloggen, aber es ist sehr empfehlenswert, dass Du dich einloggst. In privaten Wikis ist das Einloggen für jeder API-Funktinalität erforderlich.
 * 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.

Siehe auch

 * - Gibt Informationen über den aktuell eingeloggten Benutzer zurück