JarsAuth

# JarsAuth The description is generated by ChatGPT and proofread by the mod author. In case of any ambiguity, please refer to Chinese texts. For detailed Chinese description, please go to [客户端管理 (JarsAuth) - MC百科|最大的Minecraft中文MOD百科](https://www.mcmod.cn/class/11107.html) If you want to leave a comment, please go to [GitHub Discussion](https://github.com/Jissee/JarsAuth/discussions) --- ## Important Notice The mod has been updated to **version 6.0**. This is a **major update**, and **configurations are NOT compatible with 5.x or earlier versions**. Therefore: * **Server-side configurations must be regenerated** * **Clients must also update the mod**, but **no client-side configuration is required** * Version **5.x contains a critical bug that causes abnormally high CPU usage** and is no longer recommended This issue has been **fixed in 6.0** --- ### Configuration System Changes * All configurations have been **migrated to an SQLite database** * No scattered config files will be generated anymore * The **database schema is identical across all versions**, allowing easy migration * A **built-in configuration tool** is provided: * Entry point: a new **Manager button** at the bottom of the **server GUI** * Configuration **must be performed in a GUI-capable environment** * If your server has no GUI: * Configure locally first * Then copy the database file to the server * Remote configuration support may be added in the future * The mod JAR can also be run as an **executable JAR**, automatically using the database file in the working directory * The configuration tool includes **detailed explanations** → Hover over buttons to view tooltips --- ### General Behavior * **All features are optional and disabled by default** * If no configuration changes are made, the mod behaves as if it were not installed * Features only take effect on **dedicated servers** * Supported environments: Forge, Fabric, Arclight, Mohist, etc. * **Singleplayer and LAN worlds are not affected** * All messages are stored in **language files (`*.json`)** * If you need to modify them, unpack the JAR, edit, then repackage before release * To ensure players’ right to be informed, all enabled features will be communicated to players in the form of system messages each time they connect. This message is mandatory and cannot be disabled. * Due to limited development resources: * Only **Minecraft 1.20.1 and later (stable releases)** are supported * **1.20.1 is the final Forge version** * Development will move to **NeoForge** afterward * Custom development is available upon request --- ## Feature 1 – File Checksum This is the **original feature** of the mod. ### Use Cases Normally, mod loaders only check whether **required mods** match between client and server. They do **not** detect: * Client-only mods (e.g. minimaps, performance mods, cheat mods) * X-ray or other resource packs This severely impacts **game fairness**. Traditional countermeasures (e.g. fake ores) may corrupt chunk data or cause lag. This mod’s **File Checksum** feature can: * Verify that **all client-side files**, including client-only mods, match the versions used when the modpack was created * Detect unauthorized client-only files Examples: * If minimaps are **not allowed**, clients with a minimap mod will be **denied connection** * If minimaps are **required**, clients missing it will also be **denied** * If the server updates some mods but clients do not: * Mod loader checks may still pass * Version mismatch can corrupt server data → This mod can block outdated clients by disabling their validation channel --- ### How It Works 1. The mod scans all configured files and computes their **hash values** 2. All hashes are merged into a **single client signature** 3. When a client connects: * The server periodically sends a list of files to verify * The client computes and returns its signature 4. If the signature is **not in the server’s record**, the connection is rejected --- ### Important Configuration Changes * Supports **group-based management with inheritance** * Different client groups can have different validation rules * Filters support: * Simple wildcards * Regular expressions * **Exclusion filters** can ignore files that should not be checked (e.g. `.DS_Store`, `desktop.ini`) --- ## Feature 2 – Client Authentication This feature functions similarly to a **login system**. ### Use Cases In **offline-mode servers**, player identity is based solely on usernames, making impersonation easy. This feature adds a **dedicated authentication mechanism**, preventing other players from logging in using the same username. --- ### How It Works * When a player joins: * The server checks if an ID (UUID) exists for that username * If none exists: * The player is treated as a first-time login * If one exists: * The server requests the ID from the client * If the client cannot provide it within a time limit, the connection is rejected * On first login: * The server generates an ID bound to the username * The ID is sent to the client and stored server-side * The client is then disconnected and must reconnect for verification --- ## Feature 3 – Server License ~~This feature can be used as an **anti-addiction** feature.~~ ### Use Cases Servers may want to: * Limit player playtime * Require explicit server owner authorization This feature provides a **fine-grained whitelist system** where: * The server issues licenses * Only players with **valid licenses** may connect * Licenses include: * Expiration time * Type * Usage quota --- ### How It Works On login, the server checks the player’s license: * No license * License expired * License quota exhausted → Connection is denied Licenses are also revalidated periodically during gameplay. > This feature is **entirely server-side** and does **not require client data exchange**. --- ### Important Configuration Changes * Users and rules support **grouping with inheritance** * Removed “connection-count–based” license type * Added **periodic licenses** that automatically reset or clear quotas --- ## Feature 4 – Signing & Obfuscation (Beta) > **Note:** This feature must be used inside a Minecraft environment. > Running the JAR directly does not support it. ### Use Cases Servers may want players to use **only the modpack provided by the server**. This feature allows: * Exporting **signed mod packages** to ensure uniqueness * One-click generation of **ProGuard obfuscation configs** --- ### Important Notice * The mod release page only provides **unsigned packages** (“original packages”) * **Signed packages are never distributed from public web resource** * Server owners must decide whether to use signed/obfuscated versions --- ## Setup Starting from **6.0**, strict network channel checks have been removed. Client and server can run independently without breaking gameplay. | Server Installed | Client Installed | Result | | ---------------- | ---------------- | ----------------------------------------------------------- | | Yes | Yes | Validation follows configuration | | Yes | No | Validation always fails if enabled; otherwise no validation | | No | Yes | No validation | | No | No | No validation | --- ## Preparation Steps 1. Finalize your modpack and ensure: * All mods and files are correctly placed * Server and client can start and connect normally 2. Download the **original package** 3. Place it in both server and client `mods` folders 4. Start the server 5. Open the **configuration tool** via server GUI 6. Enable or disable required features in the **Config** tab --- ## Signing (Optional) * In the **Signing** tab: * Generate: * `*-signed.jar` (server) * `*-signed-expanded.jar` (client) * These must match exactly * A `config.pro` file is also generated * Import into ProGuard to generate: * `*-signed-expanded-obj.jar` * Obfuscation applies **only to client packages** * Replace: * Server mod with server signed JAR * Client mod with corresponding signed/obfuscated JAR * Restart the server --- ## File Checksum Workflow 1. Start client and server 2. Run `/jarsauth record on` on the server (File Checksum must be enabled) 3. Client connects → files are recorded → client is disconnected 4. Switch config tool pages to refresh UI 5. Run `/jarsauth record off` 6. Select client groups and configure filters → Changes apply immediately --- ## Client Authentication Notes * Config tool shows: * Server ID * All recorded client IDs * To revoke a player: * Delete their ID entry * Client-side: * A database file is created in the client root directory * It stores all username–ID mappings * **Must be backed up carefully** * Loss → cannot log in * Leak → account impersonation risk * Multi-device use → copy the database file --- ## Server License Notes * Configure groups in the tool * A mandatory `default` group applies to all users * Players may belong to multiple groups * Group relationship is **OR** * If any group has remaining allowance, access is granted * All group allowance decrease simultaneously * Effective allowance = highest available among groups --- ## Configuration Reload Notice * Configuration **reload is no longer supported** * Enabling/disabling features requires a **server restart** * Other configuration changes take effect immediately --- ## Mod Author's Words This part has been moved to GitHub.