3 Limbo players

ljacqu edited this page 2017-03-26 23:08:02 +02:00

Table of Contents

• Introduction
• Implementation
• Timing / overriding issues
• Persistence (saving to the file system)

Introduction

Before a player is logged in, we put the player in what we call a limbo state. In this limbo state, we remove various permissions from the user before he is logged in for security:

• OP status (removed)
• ability to fly (removed)
• walk speed*
• fly speed*

* Removed only if unauthenticated players may not move (settings.restrictions.allowMovement).

Implementation

To remove properties from unauthenticated players only temporarily, we need to ensure that we keep the values for when the player logs in. We store this data as a so-called limbo player. This is an object that contains the limbo properties we've removed, i.e. OP status, flight ability, walk speed, and fly speed.

A typical chain of events is:

1. player joins
2. we create a limbo player and remove limbo properties such as OP status
3. player logs in
4. we add back all properties from the limbo player to the now authenticated player

Timing / overriding issues

One issue with this handling is that if things are changed for an unauthenticated player, we will override the new changes with the limbo player once he logs in. So a player who is set to be allowed to fly will no longer be able to fly after he logs in.

Consider the following example:

1. player joins with walk speed 5
2. we create a limbo player (keep walk speed = 5 in limbo player, set walk speed 0 on player)
3. an admin sets walk speed 10 on the player
4. player logs in
5. we restore limbo properties -> player has walk speed 5 again

We try to combat such issues by allowing you to configure how we should restore the limbo properties. You can find these settings in your config.yml under "limbo". For example, you may choose to keep the maximum speed from player and limbo player, or you can define to set "allow flight" always to true when a player logs in.

Note that restoring the OP status is not configurable. For security reasons, if an unregistered player is OP, he will no longer be OP once he registers & logs in. Similarly, an unregistered player who gets opped will no longer be OP when he logs in. In order to set someone as OP successfully, he needs to be authenticated.

Persistence (saving to the file system)

If your server crashes, we may not get the chance to restore the properties we've removed from the player. So after restarting a crashed server, it may happen that a player will have walk speed 0.

To combat this, we store limbo players in the file system. So what we actually do is this:

1. player joins
2. we create a limbo player and remove the limbo properties from the player
   • we keep the limbo player in memory, as well as in a file on the file system
3. player logs in
4. we restore the limbo properties
   • remove limbo player from memory, delete file

The file is a backup so that this data is somewhere outside of memory, in case the server crashes. In config.yml, under limbo, you can configure if and how limbo players should be saved. We offer individual files, one huge file, or the possibility to distribute the data over a configurable number of files.

• Home
• For plugin users
  • AuthMe releases (Jenkins)
  • Breaking changes
  • Spawn handling
  • Name restrictions
  • Registration
  • Limbo players
  • Converters
  • Logging
  • Use Argon2
  • Forum integrations
  • Development team
  • Translators
  • Forge mods compatibility
  • 5.4 changelog
  • 5.3 changelog
  • 5.2 changelog
• For developers using AuthMe
  • Hooking into AuthMe
  • Plugins hooking into AuthMe
• For developers
  • Coding styleguide
  • Command handling
  • Dependency injection
  • Development setup
  • Limbo architecture
  • Tool tasks
  • Unit testing