Description
When nLogin premium auto-login is enabled, premium players bypass the
/register command. AzLink currently only listens to nLogin's
RegisterEvent, so these players are never created in Azuriom.
The same problem may affect Bedrock players authenticated through
BedrockLoginEvent.
This prevents those players from using Shop guest purchases because the
Shop username login requires the player to already exist in Azuriom's
users table.
Environment
- Azuriom: 1.2.12
- AzLink: 1.3.13
- nLogin: 2.0.19
- Platform: BungeeCord-compatible proxy (NullCordX)
- Java: 22
- Shop guest purchases: enabled
- Premium auto-login: enabled
Steps to reproduce
- Enable premium auto-login in nLogin.
- Use a premium player that does not already exist in Azuriom.
- Join the server.
- nLogin authenticates the player automatically without
/register.
- Check the Azuriom users table or try Shop guest login with that username.
Current behavior
The player is not created in Azuriom because
NLoginIntegration only handles RegisterEvent.
Non-premium players that execute /register are synchronized correctly.
Expected behavior
A player successfully authenticated through PremiumLoginEvent should be
created or updated in Azuriom using:
- Minecraft username
- verified UUID
- IP address
- nullable email
- no password, allowing Azuriom to generate a random password
BedrockLoginEvent should probably use the same flow.
Suggested implementation
- Listen to
PremiumLoginEvent and optionally BedrockLoginEvent.
- Add a registration method that supports a missing password.
- Do not send the
password JSON property when it is null, so Azuriom can
generate a random password.
- Make registration idempotent by UUID/game_id because premium login events
may be fired on every connection.
- Apply the behavior consistently to Bukkit, BungeeCord and Velocity
integrations.
A companion change may be needed in Azuriom's register endpoint. It currently
validates name and game_id as unique before checking whether a user with
that game_id already exists, so the existing update branch appears
unreachable for already synchronized players.
Description
When nLogin premium auto-login is enabled, premium players bypass the
/registercommand. AzLink currently only listens to nLogin'sRegisterEvent, so these players are never created in Azuriom.The same problem may affect Bedrock players authenticated through
BedrockLoginEvent.This prevents those players from using Shop guest purchases because the
Shop username login requires the player to already exist in Azuriom's
userstable.Environment
Steps to reproduce
/register.Current behavior
The player is not created in Azuriom because
NLoginIntegrationonly handlesRegisterEvent.Non-premium players that execute
/registerare synchronized correctly.Expected behavior
A player successfully authenticated through
PremiumLoginEventshould becreated or updated in Azuriom using:
BedrockLoginEventshould probably use the same flow.Suggested implementation
PremiumLoginEventand optionallyBedrockLoginEvent.passwordJSON property when it is null, so Azuriom cangenerate a random password.
may be fired on every connection.
integrations.
A companion change may be needed in Azuriom's register endpoint. It currently
validates
nameandgame_idas unique before checking whether a user withthat
game_idalready exists, so the existing update branch appearsunreachable for already synchronized players.