Minecraft Event Whitelists: Verify Access Removal
To revoke access to a Minecraft event, verify three outcomes: the account is no longer authorised, its active session ends when the event policy requires it, and a fresh connection is refused. Then repeat the check after a restart and a roster synchronisation. Removing a name from a website does not establish that the server has applied the change.
This rehearsal is for organisers running a private Java/Paper event. It can form part of accepting a server configuration or a registration integration. The outcomes below are proposed requirements to test in your environment, not results measured by Mineando or guarantees about every plugin.
Define what removal means
Before changing the whitelist, separate three operating decisions: closing registration, refusing new connections and ending a session already in progress. Closing a form may leave registered participants' access intact. Removing someone's building permissions also does not answer whether they can remain connected.
For this rehearsal, agree a simple rule: once the responsible organiser confirms a withdrawal, the account loses access to the event server, including an existing session. Keep this separate from eliminating someone from a round while allowing them to spectate. That case changes their role inside the game and may not require removing server admission.
Name the person who approves removal, the person who applies it and the person who verifies the outcome. If staff powers also need to end, use the separate procedure for temporary event staff permissions. Admission and moderation rights are distinct checks, even when they concern the same account.
Find the authoritative list
In Paper, white-list enables restricted admission, while enforce-whitelist controls kicking players who are not on the list. Check both in the server.properties reference. Enabling one setting alone is not evidence that the complete removal procedure works.
The data file documentation identifies whitelist.json as the permitted-player list and recommends managing it through /whitelist rather than editing the file directly. Use a correctly identified ordinary account and the supported management procedure for your deployment.
If a website or plugin produces the list, also document which record is authoritative. A later import could undo a manual server-side removal if its source still contains an active registration. That is a failure scenario to reproduce in your system, not a claim about the behaviour of every plugin.
Rehearse with two ordinary accounts
Prepare a staging copy with the same software versions and admission configuration. Use one account whose access will be removed and a second that should retain access. Neither should have OP or administrative exceptions during this test; check those exceptions separately.
- Confirm that both accounts can join through the address advertised for the event.
- Leave the account selected for removal connected.
- Record the withdrawal in the authoritative system and apply it to the server. For the native whitelist, removal uses
/whitelist remove TestPlayer; replace the example name with your controlled account. - Observe whether the session ends. If it remains connected, immediate removal has not passed. Apply the explicit disconnection step in your procedure and record that it was required.
- Attempt to reconnect with the removed account. Keep the refusal message and timestamp.
- Reconnect the control account to confirm that you have not accidentally blocked everyone.
Paper's permission reference lists separate command permissions for whitelist and kick. If your procedure needs both, agree who may execute them. Do not give participants broad administrative access to work around admission problems.
Check that automation does not restore access
The decisive part begins after the first refused connection. With the removed account still outside, run the normal registration synchronisation cycle. Then restart the staging server through its usual procedure. Attempt another connection after each step.
| Checkpoint | Required outcome for the removed account |
|---|---|
| After removal is applied | Session ends under the agreed policy; a new connection is refused |
| After roster synchronisation | Account does not become authorised again |
| After restart | Account still cannot join |
| After an approved readmission | Only the intended access is restored |
If synchronisation restores access, fix the source record or reconciliation rule. Repeating manual removals every few minutes hides the defect. When commissioning the integration, require an “access removed” state to reflect confirmation from the destination. Until then, it should display a pending state or an observable failure.
Also rehearse an interrupted synchronisation: the website records the withdrawal, but the server does not receive it. Decide who detects that discrepancy and how they finish the removal. The application deadline is a project requirement to measure; this guide does not supply a universal response time.
An event operator needs a useful handover here. Record where pending changes appear, who can retry them, and how a resolved case is checked. Avoid a workflow in which a successful web request silently becomes the only evidence of enforcement.
Set the boundary of the result
Passing this test on one server does not establish the same behaviour across a network. If you have a lobby, multiple destinations or Bedrock entry, identify which system recognises the account and where admission is checked. Repeat the case through each supported route. Review protection against direct backend connections using the Velocity and Paper isolation guide.
Hand over a record containing versions, controlled account identities, starting state, actions, timestamps, expected outcomes and actual outcomes. Mark any unexecuted case “not run”. Keep only the necessary account information in the internal record; do not publish real participant rosters in an event report.
Accept the procedure when removal, persistence and controlled readmission all work while the control account retains access. To include this rehearsal in a Minecraft event project, bring the admission rule, involved systems and schedule to the scope discussion. Mineando quotes paid projects individually; support and live coverage are agreed separately.
