Dashboard: login, accounts & permissions

The web dashboard is the control center for moderation and administration. This page explains how to log in, what is under Mein Konto ("My account"), how staff members request permissions and how admins grant them.

Requirements

• The REST API is running (EternalApi-<ver>.jar, configuration in api.yml).
• On the proxy and Spigots, in config.yml:

api:
  enabled: true
  base-url: http://localhost:7070      # address of the REST API
  shared-secret: ""                   # same value as internal.shared-secret in api.yml
  poll-interval-seconds: 3            # polling of the action queue (web → in-game)

• In api.yml:

internal:
  shared-secret: "REPLACE_WITH_RANDOM_INTERNAL_SECRET"
session:
  ttl-seconds: 86400        # duration of a web session (24 h)
  link-ttl-seconds: 300     # validity of the in-game code (5 min)
accounts:
  enabled: true
  min-password-length: 8
  login-attempts-per-10min: 10
server:
  trust-forwarded-for: false   # true behind Caddy/nginx/Apache

Logging in

The login page has three tabs:

Account link (in-game code)

1. Click Code generieren ("Generate code") – the dashboard shows a code.
2. Enter /eternal link <Code> in-game (within session.link-ttl-seconds).
3. The dashboard logs you in automatically.

Every player may use /eternal link; no permission is needed. In a network, the proxy answers the command – it must have api.enabled: true with the correct secret, otherwise you get „Die REST-API ist nicht konfiguriert“ ("The REST API is not configured").

Password

Banned players cannot link in-game. So that they can still get into the dashboard (submit an appeal, watch the replay of their ban), there are password accounts:

1. Log in once via account link.
2. Mein Konto → Dashboard-Konto ("My account → Dashboard account"): set a password. Permission eternal.web.account (default level All).
3. From then on, log in on the Passwort ("Password") tab with Minecraft name + password – even while banned.

• Passwords are stored with PBKDF2-HMAC-SHA256 (210,000 iterations, 16-byte salt).
• Brute-force protection: login-attempts-per-10min per IP + name, plus five times that per IP regardless of the name (then HTTP 429).
• Changing the password or deleting the account (each with the current password) ends all other sessions.
• After a name change, the new name is picked up on the next code login.

API key

For admins: enter a static key from api.yml.

api-keys:
  - key: "REPLACE_WITH_RANDOM_STRING"   # at least 32 characters
    name: "Admin-Bootstrap"
  # - key: "second-key-xyz"
  #   name: "Tooling"
  #   uuid: "00000000-0000-0000-0000-000000000000"   # optional: player for rank protection

An API key has full access without permission checks – the guaranteed emergency access in case no rank has dashboard permissions yet. However, it has no player account: claiming reports, teleporting and other in-game actions do not work with it.

My account

Every logged-in player sees:

• Profilkarte ("Profile card") with rank, tier, display name, coins and district – with links to Mein Profil ("My profile", the player page as staff see it: history, nick history, appeals) and Mein Inventar ("My inventory": own inventories, overflow store, items). Both work without a team permission – everyone may see their own data.
• Deine Grundstücke ("Your plots"): every own plot with world, id, district and size (see Plots).
• Du bist aktuell gemutet ("You are currently muted") when a mute is active.
• Dashboard-Konto ("Dashboard account"): set or change the password, delete the account.
• Deine Moderation ("Your moderation", for staff members): counters of your own bans, mutes and handled reports.
• Replays zu deinen Banns ("Replays of your bans", eternal.replay.own): the replay behind your own ban, see Replays.
• Aktiver Bann ("Active ban") with Entbannungsantrag stellen ("Submit unban appeal"), below it Frühere Anträge ("Previous appeals"). See Bans & Mutes.
• Deine Historie ("Your history"): your own punishments.

Under Coins & Markt ("Coins & market"), everyone sees their balance (see Coins & stock market).

Where dashboard permissions come from

There are no fixed roles such as ADMIN/MOD/PLAYER. What someone may do in the dashboard results solely from permissions with the prefix eternal.web.* (plus moderation permissions such as eternal.ban, eternal.report.handle). Every check uses this order – the first answer wins:

1. User override – a personal grant or denial for exactly this player (e.g. from an approved permission request).
2. Eternal Perms – permissions of the player's ranks and their own permissions, including wildcards and denials.
3. Legacy CloudNet mirror – permissions of the CloudNet group from earlier versions.
4. Legacy web role – permissions from the Rollen & Rechte ("Roles & permissions") editor.
5. Default level of the permission (see Permissions reference).

One place for every permission: "Rollen & Rechte" (ranks) and "Benutzer & Ränge" (players) have a single editor – in-game and dashboard permissions in one searchable list, grouped by area or plugin, each Erlaubt (allowed), Verboten (denied) or – (optionally with potency and expiry). Every permission says what it does: the description from Eternal or the plugin.yml; permissions only found in a plugin's code get a generated description (e.g. worldedit.region.set → "WorldEdit: Region – setzen"). Old dashboard permissions (web roles, personal overrides) appear there with the badge alt and are moved into the rank's / player's permissions on save; old dashboard roles without a rank can be turned into a rank with one click.

Eternal Perms ranks grant eternal.web.* directly. A rank "Moderator" with eternal.web.dashboard, eternal.web.player.view and eternal.report.handle sees exactly these areas – a separate web role is no longer needed. Wildcards work: eternal.web.* grants all dashboard permissions, * everything. A denial on the exact key beats a broader wildcard (e.g. eternal.web.* allowed, eternal.web.admin denied = everything except the admin area).

The dashboard hides menu items without a matching permission. The API additionally checks every permission on the server side (HTTP 403, without logging you out).

Requesting permissions (for staff)

Anyone with eternal.team sees Admin → Rechte bestellen ("Request permissions", /access-requests) in the menu:

• Two tabs: Ingame (all eternal.* permissions except eternal.web.*) and Website (eternal.web.*).
• Free-text search across title, key, description and keywords (e.g. „kisten sperren“, "lock chests") – all words must match.
• Warenkorb ("Cart"): collect several permissions, one shared justification, one request. Permissions you already hold („Hast du“, "You have") and ones already requested are skipped.
• Pakete ("Bundles"): bundles put together by the admin; one click puts all still-missing permissions into the cart.
• Notices „Wirkt nur mit …“ ("Only works with …"; missing prerequisites, marked red) and „Empfohlen dazu …“ ("Recommended with …").
• Meine Anfragen ("My requests"): status of your own requests.

Permission requests (for admins)

Admin → Rechte-Anfragen ("Permission requests", /admin/permission-requests), permission eternal.web.admin:

• Freigeben ("Approve") writes the permission as a user override for the requester only – permanently or time-limited (1 day, 7 days, 30 days).
• Ablehnen ("Reject") only records the decision.
• Approvals take effect in-game immediately: the override is reported to the servers and applied.
• Expired approvals automatically stop counting; when the list is opened, they are cleaned up and the request is set to „abgelaufen“ ("expired").

Permission catalog (for admins)

Admin → Rechte-Katalog ("Permission catalog", /admin/permission-catalog), permission eternal.web.permissions.catalog:

• Per permission, override the description (empty = built-in text) and maintain keywords for the search.
• Change the default level per permission (Aus / Team / Admin / Alle – Off / Team / Admin / All) – the built-in level is shown next to it.
• Create, edit and delete bundles (identifier a-z, 0-9, -).
• Everything is stored as permission-meta.yml in the database and can be transferred between networks.

Users & ranks, overrides

Admin → Benutzer & Ränge ("Users & ranks", /admin/users), permission eternal.web.admin:

• Search all known players (offline too).
• View, add and remove the player's ranks.
• Personal permission overrides: per permission Erlauben ("Allow"), Verbieten ("Deny") or „Rolle“ ("Role" = back to the rank's default). The filter „Nur gesetzte“ ("Only set") shows all of the player's overrides.

Overrides beat everything else, including the ranks – use them deliberately for exceptions.

Legacy roles (Rollen & Rechte)

Admin → Rollen & Rechte ("Roles & permissions", /admin/permissions) is the role editor from before Eternal Perms. With CloudNet, it shows the CloudNet groups; without CloudNet, you can create your own roles and assign them to a group. The permissions there still apply (level 4 of the order above), but are overridden by the Eternal Perms ranks.

Other admin pages

Recommended rank permissions

Common pitfalls

• „Code unbekannt oder abgelaufen“ ("Code unknown or expired") when linking: the code expired (5 minutes) or api.enabled/the secret on the proxy is wrong.
• Login works, but the menu is empty: the rank has no eternal.web.* permissions and no eternal.team. Log in with the API key and grant permissions.
• A staff member does not see „Rechte bestellen“: eternal.team must be granted explicitly (rank, override or wildcard) – it never applies via the default level.
• All logins blocked (429): trust-forwarded-for is missing behind the reverse proxy.
• Override does not behave as expected: overrides beat everything. Check „Nur gesetzte“ for the player and reset to „Rolle“.