AuthRecoveryUI - Modern Login & Register v๊๊Update 1.2.4

AuthRecoveryUI — Modern Login, Register & Recovery UI
Upgrade AuthMe with a modern, vanilla-friendly authentication experience powered by Minecraft's native Dialog API (1.21.7+).

No client mods or resource packs required — vanilla clients supported.


Why Choose AuthRecoveryUI​

• AuthMeReloaded 5.7.x forks tested
• AuthMe 6.0.0+ supported — set dialogs.replace-authme-native-dialogs: false, or turn off AuthMe’s useDialogUi, to avoid duplicate dialogs.

• Plugin JAR (all dependencies included)
• Fully documented config.yml
• 5 language files
• Configuration guide
• Commands & permissions reference

#######################################################
#
# AuthRecoveryUI - Login / Register / Password recovery
# dialogs for AuthMe, built on the Paper Dialog API.
#
# Every piece of text below is a MiniMessage string, so you can freely
# use tags like <gold>, <bold>, <gray>, <green>, <red>, <yellow>, <#RRGGBB>
# etc. to restyle everything without touching any Java code.
#
# Colour scheme used by the defaults (feel free to change):
# gold / bold -> dialog titles
# gray -> normal body text
# green -> success messages + primary/confirm buttons
# yellow -> warnings + secondary/informational buttons
# red -> errors + destructive actions
# gray button -> neutral "Cancel"
#
# Every piece of text on this page is the ENGLISH (en_US) text and doubles
# as the fallback used whenever a translation is missing a key - see the
# "language:" section below and the lang/ folder for the other languages.
#
#######################################################

dialogs:
# Allow players to close dialogs by pressing escape.
# Kept false for login/register/recovery so players can't dodge auth.
allow-escape-close: false
# Global default width (in pixels) for every dialog's input box(es). Override this for a
# single dialog by adding "input-width: <number>" directly under that dialog's own section
# below (e.g. under login-dialog - a per-dialog value always wins over this global one.
input-width: 220
# AuthMe 6.0.0+ ships its OWN native login/register dialog UI, controlled by TWO independent
# settings in AuthMe's own config.yml (not this file), both under settings.registration.* and
# both DEFAULT TO TRUE on a fresh AuthMe 6.0.0 install:
# settings.registration.useDialogUi - shows AuthMe's dialog the SAME way this
# plugin does (Player#showDialog() after
# the join event) - genuinely conflicts with
# this plugin if both are left on. Requires
# Minecraft 1.21.6+ on Spigot, 1.21.11+ on Paper.
# settings.registration.usePreJoinDialogUi - shows AuthMe's dialog BEFORE the player
# even joins (Paper/Folia 1.21.11+) - no
# direct conflict, but this plugin's dialogs
# simply never get a chance to show, since
# the player is already authenticated by the
# time our join listener runs.
# Since BOTH of AuthMe's own toggles default to true, installing AuthMe 6.0.0 fresh WILL show
# duplicate/competing dialogs unless you set this to FALSE. Leave it TRUE for older AuthMe
# builds (e.g. 5.7.x forks) that have no native dialog UI of their own - that's this plugin's
# primary use case. The plugin also logs a startup warning if it detects AuthMe 6.0.0+ while
# this is still true, as a safety net.
replace-authme-native-dialogs: true
# How long (seconds) to wait right after a player joins, before deciding whether they're
# registered - re-checked repeatedly during this window rather than a single snapshot. This
# matters if you also run a third-party premium-account plugin (e.g. FastLogin) that
# auto-registers verified players with AuthMe asynchronously: its whole verify-with-Mojang +
# register + log-in sequence can easily take longer than an instant, so a single check taken
# right at join can catch it mid-way and incorrectly show Rules/Register to a player who
# already has (or is about to have) an account. If you don't use any such integration, this
# can safely be lowered (even to 0) for a snappier first-join experience for genuinely new
# players - the default of 3 favors correctness with FastLogin-style setups.
registration-check-seconds: 3
# How long (seconds), AFTER the Rules/Register dialog has already been shown, to keep watching
# in the background for a LATE external auto-register+login (e.g. FastLogin's Mojang
# verification finishing after the window above already elapsed) - if it happens, the
# now-stale dialog is closed automatically instead of leaving a player who can already move
# around (AuthMe unlocked them) stuck looking at a Register prompt that no longer applies.
registration-watch-after-shown-seconds: 20
# ----------------------------------------------------------------
# Logo/banner shown at the very top of dialog bodies (below the title,
# above everything else). Empty by default (disabled). Two ways to use it:
#
# 1) Plain colored ASCII-art text, no extra plugin needed, e.g.:
# logo: "<gold><bold>MY SERVER</bold></gold>"
#
# 2) A real image, via ItemsAdder (or any resource-pack plugin that provides
# a custom font): ItemsAdder lets you define a custom font character that
# renders as an actual image through your resource pack. Wrap that
# character in MiniMessage's <font:...> tag pointing at ItemsAdder's font,
# e.g.:
# logo: "<font:itemsadder:default>\ue000</font>"
# (replace \ue000 and the font key with whatever your ItemsAdder icon
# actually uses - check /iaeditor or your resource pack's font.json for
# the exact character and font key it generated for that icon).
#
# Applies to ALL dialogs by default. Override for a single dialog by adding
# a "logo:" key directly under that dialog's own section below (e.g. under
# login-dialog - a per-dialog logo always wins over this global one.
logo: ""

# ------------------------------------------------------------------
# Language - which text file each dialog's text is read from.
# ------------------------------------------------------------------
# Supported codes: en_US, th_TH, zh_CN, es_ES, pt_BR, fr_FR
#
# en_US always comes straight from THIS file (the "*-dialog:" sections below) - there is no
# separate lang/en_US.yml. The other five languages live in individually editable files under
# plugins/AuthRecoveryUI/lang/ (extracted automatically the first time the plugin starts, or
# after /authrecoveryui reload if missing). Any key you haven't translated yet in one of those
# files - or an entire missing file - just falls back to the English text on this page, so a
# partial translation can never produce a blank dialog.
language:
# Server-wide language used for every player, unless per-player-auto-detect (below) is on
# and a supported translation matches that player's own client language.
default: en_US
# If true, each player automatically sees dialogs in their OWN client's language (Options ->
# Language in Minecraft) whenever we have a translation for it, regardless of "default" above -
# players using an unsupported language still see "default". If false (the default), every
# player always sees the "default" language above, regardless of their client's own setting.
per-player-auto-detect: false

# ------------------------------------------------------------------
# Password policy - applies to the password field(s) in every dialog below.
# ------------------------------------------------------------------
password-policy:
min-length: 8
max-length: 64
# Whether the min-length requirement above is also enforced on the LOGIN dialog's password
# field. Defaults to false ON PURPOSE: Login verifies an EXISTING account password, which may
# have been created before this policy existed (or by another plugin/import) - rejecting a
# login attempt for being "too short" would lock real players out of accounts that already
# work fine as far as AuthMe itself is concerned. The max-length cap is always applied to
# Login regardless of this setting, since 64 characters is generous enough that no real
# password should ever legitimately hit it.
enforce-min-length-on-login: false
# Any of the *-dialog sections below can override either number just for that one dialog by
# adding "password-min-length:" / "password-max-length:" directly under it, e.g.:
# new-password-dialog:
# password-min-length: 10

# ------------------------------------------------------------------
# SMTP - used ONLY for pre-registration email verification (Confirm Email
# dialog below). This is completely separate from AuthMe's own mail settings
# (which AuthMe uses for password recovery) - set your own Gmail/SMTP here.
# ------------------------------------------------------------------
smtp:
# Master switch: if false, registration skips straight to creating the
# account (old behaviour) - no Confirm Email step, no email sent by us.
enabled: false
host: smtp.gmail.com
port: 465
# ssl: true expects an implicit-TLS port (Gmail: 465). If your provider instead uses STARTTLS
# on port 587, set ssl: false AND change port to 587 - leaving port at 465 with ssl: false
# (or vice versa) is a common misconfiguration that will fail every send.
ssl: true
username: '[email protected]'
# Gmail: use an App Password (Google Account -> Security -> App passwords),
# never your real account password.
password: 'your-app-password'
# Safe to use spaces or any display characters here - passed to JavaMail as a proper
# personal-name parameter, which handles the required quoting/encoding on its own.
from-name: "MINK SMP"
subject: "Your verification code: %code%"
body: |-
Your verification code is: %code%
This code expires in %minutes% minutes.
If you didn't request this, you can ignore this email.
code-length: 6
code-valid-minutes: 10
max-attempts: 5
resend-cooldown-seconds: 60
# Mailbox callout ("SMTP verification"): before sending, connect to the recipient domain's OWN
# mail server (port 25) and ask via RCPT TO whether the exact mailbox exists - this catches
# fake mailboxes on real domains (e.g. [email protected]: Gmail answers "550 ... does not
# exist" immediately). STRICTLY fail-open: only a definitive permanent rejection counts as
# "doesn't exist" - if your host blocks outbound port 25 (common on game hosting), or the
# check times out / gets greylisted, it is silently skipped and the flow behaves exactly as
# before (the emailed code the player must type back remains the real proof). Catch-all
# domains that accept every address will still pass this check.
mailbox-precheck: true
# Bounce detection - the "email doesn't exist" signal that works EVEN when your host blocks
# outbound port 25 and mailbox-precheck above can never run: when a verification email is sent
# to a nonexistent mailbox, the provider bounces a failure notice back to the SENDER's inbox
# (for a fake @gmail.com sent from Gmail: within seconds, with an X-Failed-Recipients header).
# The plugin logs into that inbox over IMAP (port 993 TLS - never blocked) using the same
# smtp.username/password above, checks a few times after each send, and if a bounce about the
# player's address is found, pulls them off the Confirm Email dialog back to Register with an
# explicit "this email doesn't exist" message. Fail-quiet: any IMAP trouble just skips the
# check. NOTE: Gmail app passwords work for IMAP; make sure IMAP access is enabled on the
# sending account (Gmail -> Settings -> Forwarding and POP/IMAP). Cross-provider bounces can
# take longer than the watch window - those players simply fall back to the normal
# code-never-arrives flow, exactly as before.
bounce-detection:
enabled: true
imap-host: imap.gmail.com
imap-port: 993
# How many times to check, and how far apart (seconds). Defaults cover the first ~45s after
# each send - enough for same-provider bounces, which arrive almost immediately.
checks: 3
interval-seconds: 15

# ------------------------------------------------------------------
# Login dialog
# ------------------------------------------------------------------
login-dialog:
title: "<gold><bold>\u2694 Login</bold></gold>"
# Example: give the login screen its own logo instead of (or in addition to) the global
# "dialogs.logo" above - e.g. your server's name/banner like in the reference screenshot:
# logo: "<gold><bold>THAILAND\nMYSERVER\nSURVIVAL</bold></gold>"
# or with an ItemsAdder image icon:
# logo: "<font:itemsadder:default>\ue000</font>"
# Example: give the login screen's password field its own width instead of the global
# "dialogs.input-width" above:
# input-width: 250
body: []
password-label: "Password"
submit-button: "<green>Log in</green>"
forgot-button-enabled: true
forgot-button: "<yellow>Forgot password</yellow>"
# Lets a player who doesn't want to log in right now leave the server cleanly through the
# dialog itself (kicked with quit-message below), instead of their only options being Alt+F4
# or - if dialogs.allow-escape-close is off - having no way out of this dialog at all.
quit-button-enabled: true
quit-button: "<red>Quit</red>"
quit-message: "<gray>Come back when you're ready to log in!</gray>"
wrong-password-message: "<red>\u2716 Incorrect password. Please try again.</red>"
blank-password-message: "<red>Please enter your password.</red>"
password-whitespace-message: "<red>Passwords cannot contain spaces.</red>"
# Only shown if password-policy.enforce-min-length-on-login is true above (off by default).
password-too-short-message: "<red>Password must be at least %min% characters long.</red>"
# ----------------------------------------------------------------
# Session auto-login: respects AuthMe's own "Session" feature, where a returning player
# within the session timeout gets logged in automatically without ever seeing this dialog.
# ----------------------------------------------------------------
session-auto-login:
enabled: true
# How long (seconds) to wait for AuthMe's own session check to resolve BEFORE showing the
# Login dialog at all - if the player turns out to already be authenticated within this
# window, the dialog never appears.
initial-check-seconds: 3
# How long (seconds), AFTER the Login dialog has already been shown, to keep watching in the
# background for the player becoming authenticated some other way (a slower Session
# resolution, or them typing "/login" in chat instead of using the dialog) - if that happens,
# the now-stale dialog is closed automatically instead of sitting there asking for a
# password they no longer need to type.
watch-after-shown-seconds: 20
# Shown when the player is auto-logged-in by AuthMe's Session feature (either before the Login
# dialog would have appeared, or by closing it if it was already open). Set to '' to disable.
session-auto-login-message: "<green>\u2713 Welcome back! You were automatically logged in.</green>"

# ------------------------------------------------------------------
# "Please wait" dialog shown right after the Login dialog is submitted, while AuthMe's password
# check (async) is pending. This can take up to a couple of seconds, so this keeps the player
# looking at active feedback instead of a blank screen that could read as a freeze. Always gets
# replaced automatically: success -> closed automatically once logged in, wrong password -> back
# to the Login dialog with an error.
# ------------------------------------------------------------------
verifying-login-dialog:
title: "<gold><bold>\u2699 Please Wait</bold></gold>"
body:
- "<gray>Checking your password...</gray>"
# Single do-nothing status button (Minecraft requires every dialog to have at least one).
wait-button: "<gray>Logging in...</gray>"

# ------------------------------------------------------------------
# Register dialog - password + email (AuthMe secondArg: EMAIL_MANDATORY
# means the real command is "/register <password> <email>", no separate
# confirm-password argument). Set include-confirm: true / include-email: false
# below if your AuthMe registration type is set up differently.
#
# If smtp.enabled is true above, submitting this dialog does NOT register
# the account yet - it sends a verification code first (Confirm Email dialog).
# ------------------------------------------------------------------
register-dialog:
title: "<gold><bold>\u270E Register</bold></gold>"
# Example per-dialog input width override (see login-dialog above): input-width: 250
body:
- "<gray>Create an account to start playing.</gray>"
password-label: "Password"
include-confirm: false
confirm-label: "Confirm password"
include-email: true
email-label: "Email"
submit-button: "<green>Register</green>"
# Lets a player who doesn't want to register right now leave the server cleanly through the
# dialog itself (kicked with quit-message below), instead of their only options being Alt+F4
# or - if dialogs.allow-escape-close is off - having no way out of this dialog at all.
quit-button-enabled: true
quit-button: "<red>Quit</red>"
quit-message: "<gray>Come back when you're ready to create an account!</gray>"
# Only used when smtp.enabled is FALSE (no verification code will be emailed): checks via DNS
# that the email's domain can actually receive mail (has an MX or A record) before running
# /register - catching typos like "gmial.comm" and made-up domains, so a dead recovery email
# never gets permanently attached to the new account. Fails open: any DNS trouble on the
# server's side lets the email through rather than blocking a real player.
# (When smtp.enabled is true, the same check already runs inside the email send - plus the
# verification code itself proves the player controls the inbox, which is far stronger.)
# Safety net: checks AuthMe's own database DIRECTLY (read-only, bypassing AuthMeApi entirely -
# it has no reverse email lookup) for whether this email is already registered to a DIFFERENT
# account, before starting either registration path below. AuthMe is supposed to prevent this
# itself (its own Email.maxRegPerEmail setting, default 1 account per email) - but that has
# been confirmed to NOT be reliably enforced on at least one actively-used AuthMe fork, so this
# is a belt-and-suspenders check that doesn't depend on your specific AuthMe build getting it
# right. Currently only works when AuthMe's own DataSource.backend is SQLITE (AuthMe's
# default) - fails open (skips the check, logs one warning) for MySQL/MariaDB/PostgreSQL.
check-duplicate-email: true
# Only needed if the check above can't find AuthMe's database automatically - it first tries
# "authme.db" in AuthMe's own plugin folder, then falls back to scanning that folder for a
# single *.db file. Set this explicitly (just the filename, not a full path) only if that
# auto-detection logs a warning that it couldn't find or disambiguate the file.
sqlite-database-file: "authme.db"
# Shown when check-duplicate-email (above) finds the email already belongs to another account.
email-already-used-message: "<red>\u2716 That email is already registered to another account. Please use a different one, or recover the existing account instead.</red>"
verify-email-domain: true
# --- Validation / error messages shown inline in this dialog. Set any to '' to disable. ---
blank-password-message: "<red>Please enter a password.</red>"
password-whitespace-message: "<red>Passwords cannot contain spaces.</red>"
# %min% / %max% are replaced with password-policy.min-length / max-length above (or this
# dialog's own password-min-length / password-max-length override, if set).
password-too-short-message: "<red>Password must be at least %min% characters long.</red>"
password-too-long-message: "<red>Password must be at most %max% characters long.</red>"
blank-confirm-message: "<red>Please confirm your password.</red>"
mismatch-message: "<red>Passwords don't match. Please try again.</red>"
blank-email-message: "<red>Please enter an email address.</red>"
invalid-email-message: "<red>That doesn't look like a valid email address.</red>"
# Shown when verify-email-domain (above) finds the email's domain has no mail records at all.
invalid-email-domain-message: "<red>\u2716 That email's domain doesn't exist or can't receive email. Please double-check for typos.</red>"
# Shown back on THIS dialog if the verification email could not be sent at all (bad SMTP
# credentials, network issue, DNS says the domain can't receive mail, etc.) - straight after
# the "Please Wait" dialog below closes. There's no code to resend at this point (nothing was
# ever sent), so the player just tries Register again rather than being sent to a Confirm
# Email dialog with a "Resend" button that has nothing to resend.
send-failed-message: "<red>Failed to send the verification email. Please try again, or contact staff if this keeps happening.</red>"
# Shown back on THIS dialog when smtp.mailbox-precheck (see the smtp section) got a definitive
# answer from the email's own mail server that the mailbox does not exist (e.g. a fake
# @gmail.com address) - the player needs to enter a corrected email and register again.
email-not-found-message: "<red>\u2716 That email address appears to be incorrect or does not exist. Please check it and try again.</red>"
# Shown when smtp.bounce-detection catches a delivery-failure notice AFTER the send looked
# successful - the player is pulled off the Confirm Email dialog back to this one, instead of
# waiting forever for a code that can never arrive.
email-bounced-message: "<red>\u2716 Your verification email could not be delivered - that address does not exist. Please check it and register again.</red>"
# Shown (back on this dialog) if the Confirm Email code expired, was guessed wrong too many
# times, the verification session was lost (e.g. server restarted), or AuthMe itself rejected
# the final /register command (bad password, blocked email domain, email already used, etc.).
code-expired-message: "<red>That code expired. Please register again.</red>"
too-many-attempts-message: "<red>Too many incorrect attempts. Please register again.</red>"
session-lost-message: "<red>Your registration session was lost. Please register again.</red>"
# Shown when AuthMe outright rejects the final /register command. AuthMe itself already
# prevents duplicate emails (its own Email.maxRegPerEmail setting, default 1 = one account per
# email) - but it doesn't expose an API to tell us WHICH specific requirement failed, so this
# message lists the common causes rather than pinpointing one. Note this means a duplicate
# email is only caught here, AFTER the player has already gone through the full Confirm Email
# verification cycle if smtp.enabled is true above - there's no reliable way to check for a
# duplicate email any earlier without querying AuthMe's database directly (fragile across its
# different supported backends), so this stays a possibility spelled out in the message.
failed-message: "<red>Registration failed. This could be because the email is already registered to another account, the username is taken, or the password didn't meet the server's requirements. Please check and try again.</red>"

# ------------------------------------------------------------------
# "Please wait" dialog - shown the instant Register (or Resend Code on the Confirm Email
# dialog) is clicked, while the verification email is actually being sent. The DNS check +
# SMTP handshake behind this can easily take 4+ seconds, so this keeps the player looking at
# active feedback instead of the game appearing to freeze. No buttons - it always gets replaced
# automatically by either the Confirm Email dialog (success) or the Register dialog with an
# error (failure) the instant the send finishes.
# ------------------------------------------------------------------
sending-email-dialog:
title: "<gold><bold>\u2709 Please Wait</bold></gold>"
body:
- "<gray>Sending your verification email...</gray>"
- "<gray>This only takes a few seconds.</gray>"
# Single do-nothing status button (Minecraft requires every dialog to have at least one).
wait-button: "<gray>Sending...</gray>"

# ------------------------------------------------------------------
# "Please wait" dialog shown while the Register email's domain is DNS-checked - only used on
# the smtp.enabled=false path with register-dialog.verify-email-domain: true. Usually resolves
# in well under a second; a slow DNS resolver can take up to ~3 seconds.
# ------------------------------------------------------------------
checking-email-dialog:
title: "<gold><bold>\u2709 Please Wait</bold></gold>"
body:
- "<gray>Checking your email address...</gray>"
wait-button: "<gray>Checking...</gray>"

# ------------------------------------------------------------------
# Confirm Email dialog - shown right after Register, BEFORE the account is
# actually created, when smtp.enabled is true above. Player must enter the
# code that was just emailed to them; only then does the account get made.
# Runs the real "/register <password> <email>" command on success.
# ------------------------------------------------------------------
confirm-email-dialog:
title: "<gold><bold>\u2709 Confirm Email</bold></gold>"
# Example per-dialog input width override (see login-dialog above): input-width: 250
body:
- "<gray>Enter the verification code we just sent to your email.</gray>"
code-label: "Verification Code"
submit-button: "<green>Verify Email</green>"
resend-button: "<yellow>Resend Code</yellow>"
cancel-button: "<gray>Cancel</gray>"
sent-message: "<green>\u2713 A verification code has been sent to your email.</green>"
# Shown if a Resend Code click genuinely fails to send (bad SMTP credentials, network issue,
# etc.) - unlike the initial Register failure above, staying on THIS dialog still makes sense
# here since a code may already have been sent successfully by an earlier attempt.
send-failed-message: "<red>Failed to send the verification email. Please try Resend, or contact staff if this keeps happening.</red>"
# Shown ON this dialog when a Resend Code click got a definitive answer from the email's own
# mail server that the mailbox does not exist - so the player knows to press Cancel and
# register again with a corrected email instead of retrying Resend forever.
email-not-found-message: "<red>\u2716 That email address appears to be incorrect or does not exist. Press Cancel and register again with a valid email.</red>"
# --- Validation / error messages shown inline in this dialog. Set any to '' to disable. ---
blank-code-message: "<red>Please enter the code from your email.</red>"
# %attempts% is replaced with the number of tries left.
wrong-code-message: "<red>Incorrect code. %attempts% attempt(s) left.</red>"
resent-message: "<green>\u2713 A new code has been sent.</green>"
resend-cooldown-message: "<yellow>Please wait a bit before requesting another code.</yellow>"
# Shown when the account is created and AuthMe auto-logs the player in right away.
# Set to '' (empty) to disable this message entirely.
welcome-message: "<green>\u2713 Email verified and account created! Welcome in.</green>"
# Shown only in the rare case AuthMe did NOT auto-login after registering (falls back to the Login dialog).
# Set to '' (empty) to disable this message entirely.
fallback-login-message: "<green>Account created! Please log in.</green>"

# ------------------------------------------------------------------
# Recovery dialog - step 1: ask for the account e-mail
# Runs "/email recover <email>" on submit.
# ------------------------------------------------------------------
recovery-dialog:
title: "<gold><bold>\u2190 Forgot Password</bold></gold>"
# Example per-dialog input width override (see login-dialog above): input-width: 250
body:
- "<gray>Please enter the email you registered with.</gray>"
- "<gray>The system will send an OTP code to your email.</gray>"
- "<red>\u26A0 IMPORTANT: Only emails you have registered will work!</red>"
email-label: "Email (Only the registered email!)"
submit-button: "<green>Send OTP Code</green>"
cancel-button: "<gray>Cancel</gray>"
# If true (default), the entered email is checked against the email actually registered on the
# account (via AuthMe's API) BEFORE anything is sent - a wrong email is rejected right here in
# the dialog, instead of the player being sent to the OTP screen to wait for a code that will
# never arrive. Turn off only if your AuthMe fork has API problems; AuthMe's own
# "/email recover" still validates the email either way (but its error only goes to chat).
verify-registered-email: true
# --- Validation / error messages shown inline in this dialog. Set any to '' to disable. ---
blank-email-message: "<red>Please enter an email address.</red>"
invalid-email-message: "<red>That doesn't look like a valid email address.</red>"
# Shown when the entered email doesn't match the one registered on the account (requires
# verify-registered-email above).
email-mismatch-message: "<red>\u2716 That email does not match the one registered for this account.</red>"
# Shown when the account has NO recovery email registered at all - "/email recover" can never
# work for it, so the player is told immediately instead of waiting on the OTP screen.
no-email-message: "<red>This account has no recovery email registered. Please contact staff for help.</red>"

# ------------------------------------------------------------------
# Recovery dialog - step 2: ask for the code that was e-mailed
# Runs "/email code <code>" on submit.
# ------------------------------------------------------------------
otp-dialog:
title: "<gold><bold>\u2709 Confirm OTP Code</bold></gold>"
# Example per-dialog input width override (see login-dialog above): input-width: 250
body:
- "<green>\u2713 Recovery code has been sent to your email</green>"
- "<yellow>Please check your email for the recovery code</yellow>"
code-label: "Recovery Code"
submit-button: "<green>Verify Code</green>"
cancel-button: "<gray>Cancel</gray>"
# --- Validation / error message shown inline in this dialog. Set to '' to disable. ---
blank-code-message: "<red>Please enter the code from your email.</red>"
# Shown back on THIS dialog when the whole recovery chain turns out to have failed: after
# "Set a New Password" the plugin verifies (via AuthMe's API) whether the stored password
# actually changed - AuthMe silently ignores "/email setpassword" when the OTP code entered
# here was wrong or expired, so "password didn't change" = "the code was bad". The emailed
# code is still valid on AuthMe's side, so the player can simply re-enter it correctly.
verify-failed-message: "<red>\u2716 The recovery code was incorrect or has expired. Please check your email and try again.</red>"

# ------------------------------------------------------------------
# Recovery dialog - step 3: set the new password
# Runs "/email setpassword <password>" on submit.
# ------------------------------------------------------------------
new-password-dialog:
title: "<gold><bold>\u2190 Set a New Password</bold></gold>"
# Example per-dialog input width override (see login-dialog above): input-width: 250
body:
- "<gray>Enter a new password for your account.</gray>"
- "<gray>It will be applied once your recovery code is confirmed.</gray>"
password-label: "New Password"
confirm-label: "Confirm Password"
submit-button: "<green>Set Password</green>"
cancel-button: "<gray>Cancel</gray>"
blank-password-message: "<red>Please enter a new password.</red>"
password-whitespace-message: "<red>Passwords cannot contain spaces.</red>"
same-password-message: "<red>Please choose a password different from your current one.</red>"
# %min% / %max% are replaced with password-policy.min-length / max-length above (or this
# dialog's own password-min-length / password-max-length override, if set).
password-too-short-message: "<red>Password must be at least %min% characters long.</red>"
password-too-long-message: "<red>Password must be at most %max% characters long.</red>"
blank-confirm-message: "<red>Please confirm your new password.</red>"
mismatch-message: "<red>Passwords don't match. Please try again.</red>"
# If true (default), after setting the new password we automatically try logging the player
# straight in with it (bounded to a couple of attempts - see README for why). If false, the
# player is always sent to the Login dialog to finish manually instead.
auto-login-on-success: true
success-message: "<green>Password changed and logged in successfully!</green>"
# Shown on the Login dialog after a password reset when auto-login is disabled above, OR when
# auto-login was attempted but we couldn't confirm it worked (which can also happen if the
# account has 2FA/a captcha step enabled - the password may well have changed successfully
# even though automatic login itself didn't go through). Set to '' to disable.
please-login-message: "<green>Your password has been updated. Please log in to continue.</green>"
# Neutral hand-off when AuthMeApi#checkPassword is unavailable - never claims the password
# was updated, because we genuinely could not verify the recovery chain.
unverifiable-login-message: "<yellow>Please log in with your password to continue.</yellow>"

# ------------------------------------------------------------------
# "Please wait" dialog shown after Set Password is clicked, while the plugin verifies against
# AuthMe's database whether the password REALLY changed (i.e. whether the OTP code entered
# earlier was genuinely correct). This can take a few seconds while AuthMe's async database
# write lands. It always gets replaced automatically: success -> logged in (or Login dialog),
# failure -> back to the Confirm OTP dialog with an error.
# ------------------------------------------------------------------
verifying-password-dialog:
title: "<gold><bold>\u2699 Please Wait</bold></gold>"
body:
- "<gray>Verifying your new password...</gray>"
- "<gray>This only takes a few seconds.</gray>"
# Single do-nothing status button (Minecraft requires every dialog to have at least one).
wait-button: "<gray>Verifying...</gray>"

# ------------------------------------------------------------------
# Server rules dialog (shown before registration) - Accept / Cancel.
# Cancel kicks the player with decline-kick-message.
# ------------------------------------------------------------------
rules-dialog:
enabled: true
title: "<gold><bold>\u2696 Server Rules</bold></gold>"
body:
- "<gray>- Do not use cheating software (Hacks / Cheats).</gray>"
- "<gray>- Do not advertise other servers or harass players.</gray>"
- "<gray>- Respect and honor fellow server members.</gray>"
- "<gray>- Do not use profanity or inappropriate messages.</gray>"
- "<gray>- Do not destroy others' belongings or property without permission.</gray>"
- ""
- "<white>If you understand and accept all the rules,</white>"
- "<white>please press Accept to proceed to the next step.</white>"
confirm-button: "<green>Accept</green>"
cancel-button: "<red>Cancel</red>"
decline-kick-message: "<red>You must accept the server rules to play here.</red>"

Click to expand...

Installation

Support

• Comprehensive documentation
• Discord support channal
• Bug fixes and updates
• Feature requests considered

Updates & Refund Policy

• Regular updates for new Minecraft versions
• Feature updates based on feedback
• Lifetime updates included with purchase
• Refunds are handled per BuiltByBit's Merchant Agreement — bugs are fixed promptly, or a refund is issued per platform policy. Refunds are not offered for change-of-mind purchases.