Minecraft-Event: Zugang über die Whitelist wirksam entziehen
Wenn ihr jemandem den Zugang zu einem Minecraft-Event entzieht, prüft drei Ergebnisse: Das Konto ist nicht mehr zugelassen, eine laufende Sitzung endet entsprechend eurer Veranstaltungsregel und ein erneuter Verbindungsversuch wird abgewiesen. Wiederholt die Prüfung nach einem Neustart und dem nächsten Abgleich der Teilnehmerliste. Ein gelöschter Name auf einer Website beweist noch nicht, dass der Server die Änderung umgesetzt hat.
Diese Probe richtet sich an Verantwortliche privater Events auf Java/Paper. Sie eignet sich zur Abnahme einer Serverkonfiguration oder einer Anmeldeintegration. Die beschriebenen Ergebnisse sind Anforderungen für eure Testumgebung. Es handelt sich weder um von Mineando ausgeführte Tests noch um Zusagen zum Verhalten beliebiger Plugins.
Legt fest, was ein Ausschluss bewirken soll
Unterscheidet vor einer Änderung an der Whitelist drei Entscheidungen: keine weiteren Anmeldungen annehmen, neue Verbindungen ablehnen und eine bereits laufende Sitzung beenden. Ein geschlossenes Formular kann den Zugang bereits angemeldeter Personen unverändert lassen. Auch entzogene Baurechte sagen nichts darüber aus, ob das betreffende Konto verbunden bleiben darf.
Vereinbart für diese Probe eine klare Regel: Sobald die verantwortliche Person die Abmeldung bestätigt, verliert das Konto den Zugang zum Eventserver, auch während einer laufenden Sitzung. Davon zu unterscheiden ist das Ausscheiden aus einer Runde mit anschließendem Zuschauerstatus. Dabei ändert sich die Rolle im Spiel; der Serverzugang muss nicht zwingend entfallen.
Haltet fest, wer den Entzug genehmigt, wer ihn umsetzt und wer das Ergebnis kontrolliert. Sollen zugleich Moderationsrechte enden, verwendet zusätzlich das Verfahren für befristete Teamrechte bei Events. Zugang und Befugnisse bleiben getrennte Prüfungen, auch wenn dasselbe Konto betroffen ist.
Klärt, welche Liste maßgeblich ist
Bei Paper aktiviert white-list die Zugangsbeschränkung. enforce-whitelist steuert das Trennen von Spielern, die nicht auf der Liste stehen. Prüft beide Einstellungen in der Referenz zu server.properties. Eine aktivierte Option allein belegt noch nicht, dass euer gesamtes Verfahren funktioniert.
Laut Dokumentation der Datendateien enthält whitelist.json die zugelassenen Spieler. Paper empfiehlt die Verwaltung über /whitelist statt direkter Dateiänderungen. Verwendet ein eindeutig zugeordnetes normales Spielerkonto und den für eure Installation vorgesehenen Verwaltungsweg.
Erzeugt eine Website oder ein Plugin diese Liste, dokumentiert außerdem den maßgeblichen Anmeldedatensatz. Ein späterer Import könnte eine manuelle Entfernung auf dem Server rückgängig machen, wenn die Quelle weiterhin eine aktive Anmeldung enthält. Das ist ein zu prüfendes Fehlerszenario, keine Behauptung über jedes Plugin.
Führt die Probe mit zwei normalen Konten durch
Bereitet eine Testkopie mit denselben Softwareversionen und Zugangseinstellungen vor. Ein Konto soll seinen Zugang verlieren, ein zweites ihn behalten. Beide dürfen während dieser Probe weder OP noch administrative Ausnahmen besitzen. Solche Ausnahmen prüft ihr gesondert.
- Vergewissert euch, dass beide Konten über die für das Event angekündigte Adresse beitreten können.
- Lasst das Konto, dessen Zugang entzogen werden soll, verbunden.
- Erfasst die Abmeldung im maßgeblichen System und übertragt sie auf den Server. Bei der nativen Whitelist erfolgt die Entfernung mit
/whitelist remove Testspieler; ersetzt den Beispielnamen durch euer kontrolliertes Konto. - Beobachtet, ob die Sitzung endet. Bleibt das Konto verbunden, ist das Kriterium des sofortigen Entzugs nicht erfüllt. Führt den ausdrücklich vorgesehenen Trennungsschritt aus und protokolliert, dass er nötig war.
- Versucht mit dem entfernten Konto erneut beizutreten. Haltet Ablehnungsmeldung und Zeitpunkt fest.
- Verbindet das Kontrollkonto erneut. So prüft ihr, ob versehentlich sämtliche Zugänge blockiert wurden.
Die Berechtigungsreferenz von Paper führt getrennte Befehlsrechte für whitelist und kick auf. Braucht euer Ablauf beide, legt die ausführenden Rollen fest. Gebt Teilnehmenden keine umfassenden Administrationsrechte, um ein Zugangsproblem zu umgehen.
Prüft den Entzug nach Abgleich und Neustart
Der entscheidende Teil folgt nach dem ersten abgewiesenen Verbindungsversuch. Führt den üblichen Abgleich der Anmeldungen aus, während das entfernte Konto draußen bleibt. Startet anschließend den Testserver nach eurem normalen Verfahren neu. Wiederholt den Beitrittsversuch nach jedem Schritt.
| Prüfzeitpunkt | Erwartetes Ergebnis für das entfernte Konto |
|---|---|
| Nach Umsetzung der Abmeldung | Sitzung endet nach vereinbarter Regel; neuer Beitritt wird abgewiesen |
| Nach Abgleich der Teilnehmerliste | Konto wird nicht erneut zugelassen |
| Nach Neustart | Beitritt bleibt gesperrt |
| Nach genehmigter Wiederzulassung | Nur der vorgesehene Zugang wird wiederhergestellt |
Stellt der Abgleich den Zugang wieder her, korrigiert den Quelldatensatz oder die Abgleichregel. Wiederholtes manuelles Entfernen verdeckt den Fehler. Bei einer beauftragten Integration sollte die Anzeige „Zugang entzogen“ auf einer Bestätigung des Zielsystems beruhen. Bis dahin braucht es einen sichtbaren offenen Vorgang oder einen nachvollziehbaren Fehlerzustand.
Probt auch einen unterbrochenen Abgleich: Die Website erfasst die Abmeldung, der Server erhält die Änderung jedoch nicht. Vereinbart, wer diese Abweichung erkennt und den Entzug abschließt. Innerhalb welcher Frist das geschehen muss, ist eine messbare Projektanforderung. Diese Anleitung gibt dafür keinen allgemeingültigen Zeitwert vor.
Zur Übergabe gehört deshalb auch eine kurze Betriebsanweisung: Wo stehen offene Änderungen, wer darf sie erneut anstoßen und wie wird die erfolgreiche Umsetzung geprüft? Eine erfolgreiche Anfrage an die Website darf nicht unbemerkt zum einzigen Nachweis des wirksamen Entzugs werden.
Begrenzt die Aussage der Probe
Ein bestandenes Ergebnis auf einem Server gilt nicht automatisch für das gesamte Netzwerk. Gibt es eine Lobby, mehrere Zielserver oder einen Bedrock-Zugang, klärt die Zuordnung des Kontos und den Ort jeder Zulassungsprüfung. Wiederholt den Fall über alle unterstützten Wege. Den Schutz gegen direkte Backend-Verbindungen behandelt die Anleitung zur Absicherung von Velocity und Paper.
Übergebt ein Protokoll mit Versionen, Identitäten der kontrollierten Konten, Ausgangszustand, Schritten, Zeitpunkten sowie Soll- und Ist-Ergebnissen. Noch nicht durchgeführte Fälle bleiben als „nicht ausgeführt“ markiert. Speichert im internen Nachweis nur die benötigten Kontodaten; echte Teilnehmerlisten gehören nicht in einen öffentlichen Eventbericht.
Nehmt das Verfahren ab, wenn Entzug, Fortbestand der Sperre und kontrollierte Wiederzulassung funktionieren, während das Kontrollkonto seinen Zugang behält. Soll diese Probe Teil eines Minecraft-Eventprojekts sein, bringt die Zugangsregel, beteiligten Systeme und den Zeitplan zur Abstimmung mit. Mineando kalkuliert bezahlte Projekte individuell. Support und Betreuung während der Veranstaltung werden gesondert vereinbart.
