JarsAuth

Minecraft 版本： 1.21.11

平台： fabric

标签： management utility

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百科

If you want to leave a comment, please go to GitHub Discussion

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.

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.