Whitelist en eventos Minecraft: comprueba la retirada de acceso
Para retirar el acceso a un evento de Minecraft, comprueba tres resultados: la cuenta deja de estar autorizada, su sesión activa termina cuando así lo exige la organización y un nuevo intento de entrada se rechaza. Después repite la comprobación tras reiniciar y sincronizar la lista. Quitar un nombre de una web no demuestra que el servidor haya aplicado la baja.
Esta guía propone un ensayo para responsables de eventos privados con un servidor Java/Paper. Sirve para aceptar una configuración o una integración de inscripciones. Los resultados descritos son requisitos que debes probar en tu entorno; no son pruebas ejecutadas por Mineando ni una garantía sobre cualquier plugin.
Decide qué significa dar de baja a alguien
Antes de tocar la whitelist, distingue tres decisiones de organización: cerrar nuevas inscripciones, impedir nuevas conexiones y terminar una sesión que ya existe. Cerrar un formulario puede dejar intacto el acceso de quienes estaban inscritos. Del mismo modo, retirar permisos para construir no responde a la pregunta de si esa persona puede seguir conectada.
Para el ensayo, acuerda una regla sencilla: cuando el responsable confirma una baja, la cuenta pierde el acceso al servidor del evento, incluso si estaba jugando. Mantén aparte los casos en los que una persona eliminada de una ronda debe seguir como espectadora. En ese caso cambia su función dentro del juego, no necesariamente su admisión al servidor.
Anota quién autoriza la baja, quién la ejecuta y quién comprueba el resultado. Si también hay que retirar facultades de moderación, utiliza el procedimiento de permisos temporales del equipo. Son dos comprobaciones distintas que pueden corresponder a la misma persona.
Identifica la lista que realmente manda
En Paper, white-list activa la restricción de entrada y enforce-whitelist controla la expulsión de jugadores que no estén en la lista. Revisa ambas opciones en la referencia de server.properties. No presupongas que activar una de ellas demuestra el resultado completo.
La documentación de los archivos de datos identifica whitelist.json como la lista de jugadores permitidos y recomienda gestionarla mediante /whitelist, no editarla directamente. Para el ensayo, usa una cuenta normal identificada correctamente y el procedimiento soportado por tu despliegue.
Si una web o un plugin genera esa lista, documenta además cuál es el registro autorizado. Una baja manual en el servidor puede quedar anulada por una importación posterior si el origen todavía conserva la inscripción. Este es un escenario de fallo que debes reproducir, no un comportamiento que atribuyamos a todos los plugins.
Ensaya con dos cuentas normales
Prepara una copia de pruebas con las mismas versiones y configuración de acceso. Utiliza una cuenta que vas a retirar y otra que debe conservar el acceso. Ninguna debe tener OP ni excepciones administrativas durante este ensayo: esas excepciones requieren una prueba separada.
- Comprueba que ambas cuentas pueden entrar por la dirección anunciada para el evento.
- Mantén conectada la cuenta de prueba que vas a retirar.
- Registra la baja en el sistema que manda y aplica el cambio al servidor. En una whitelist nativa, la retirada se gestiona con
/whitelist remove NombreDePrueba; sustituye el nombre por la cuenta controlada. - Observa si termina la sesión. Si sigue conectada, el criterio de baja inmediata no se ha cumplido. Aplica la desconexión explícita prevista en el procedimiento y registra que fue necesaria.
- Intenta entrar de nuevo con esa cuenta. Conserva el mensaje de rechazo y la hora.
- Reconecta la segunda cuenta para comprobar que la prueba no ha bloqueado a todos por accidente.
La referencia de permisos de Paper separa los permisos de los comandos whitelist y kick. Si el procedimiento necesita ambos, acuerda quién puede ejecutarlos. No concedas acceso administrativo general a los participantes para resolver incidencias de entrada.
Comprueba que la baja sobrevive a la automatización
El caso decisivo empieza después del primer rechazo. Con la cuenta retirada todavía fuera, ejecuta el ciclo normal de sincronización de inscripciones. Después reinicia el servidor de pruebas mediante el procedimiento habitual. Vuelve a intentar la conexión tras cada paso.
| Momento del ensayo | Resultado exigido para la cuenta retirada |
|---|---|
| Tras aplicar la baja | Sesión terminada según la regla acordada y nueva entrada rechazada |
| Tras sincronizar inscripciones | No reaparece como autorizada |
| Tras reiniciar | Sigue sin poder entrar |
| Tras una readmisión aprobada | Recupera únicamente el acceso previsto |
Si una sincronización restaura el permiso, corrige el origen o la regla de conciliación. Repetir la retirada manual cada pocos minutos oculta el problema. Si encargas la integración, pide que el estado «baja aplicada» corresponda a una confirmación del destino; mientras no exista, debería mostrar un estado pendiente o un fallo comprobable.
Ensaya también una sincronización interrumpida: la web registra la baja, pero el servidor no recibe el cambio. Decide quién detecta esa discrepancia y cómo se completa la retirada. El plazo de aplicación es un requisito del proyecto que debe medirse; aquí no se propone un tiempo universal.
La entrega al operador debe aclarar dónde aparecen los cambios pendientes, quién puede reintentarlos y cómo se verifica su resolución. Evita que una petición web completada se convierta, sin más comprobaciones, en la única prueba de que el acceso está retirado.
Delimita el resultado antes de abrir
Pasar esta prueba en un servidor no demuestra que toda una red aplique la misma decisión. Si existen lobby, varios destinos o entrada Bedrock, identifica qué sistema reconoce la cuenta y dónde se comprueba su admisión. Repite el caso por cada ruta admitida. La protección contra entradas directas a backends se revisa en la guía de aislamiento de Velocity y Paper.
Entrega un registro con versiones, identidad de las cuentas controladas, estado inicial, acciones, horas, resultado esperado y resultado observado. Marca «sin ejecutar» lo que falte. Conserva solo los datos necesarios en el registro interno; no publiques listas reales de participantes en el informe del evento.
Acepta el procedimiento cuando la baja, su persistencia y la readmisión controlada funcionen, mientras la cuenta de control mantiene el acceso. Si necesitas preparar este ensayo dentro de un evento de Minecraft, lleva la regla de admisión, los sistemas implicados y el calendario a la conversación de alcance. Mineando presupuesta cada proyecto de pago individualmente; el soporte y la cobertura en directo se acuerdan por separado.
