-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Rework whitelist and ops support #1182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This commit adds support for providing the JSON file used for ops and whitelist definitions. This is provided via the OPS_JSON and WHITELIST_JSON environment variables, and similar to OPS and WHITELIST they are copied on first run and only override the existing files if OVERRIDE_OPS and OVERRIDE_WHITELIST are set to true. If both forms of definition are provided, the JSON is processed first, with additional processing occuring with the user/uuid CSV variables. This ensures consistent behaviour with hiw options are currently used, and allows for override configuration to be provided at runtime or definition (for example a default whitelist/ops configuration, with additionals added for an event)
Minecraft 1.7.6 added support for UUIDs via the JSON configuration file format for whitelist and ops. To handle 1.7.5 and earlier, we perform slightly different logic. If Minecraft 1.7.5 or earlier: - Delete the correct files for OVERRIDE_OPS/OVERRIDE_WHITELIST - Update ops.txt and white-list.txt with users provided via variables - Error on use of JSON environtment variables As part of this change, a fix to handle existing configuration for both JSON and text-based configurations was added. If existing files are found, we uniquely merge with them.
OPS_JSON and WHITELIST_JSON have been switched to OPS_FILE and WHITELIST_FILE, to allow for their use as text files for Minecraft 1.7.5 and below. The JSON check has been removed for now.
The parser has been rewritten to individually work on usernames/UUIDs passed in the OPS and WHITELIST environment variables. If a username or UUID could not be looked up, we log a warning about the error. No failure state is created and the user is skipped. We no longer use the legacy .txt conversion for Minecraft >= 1.7.6, we now update the ops.json or whitelist.json automatically. For both old txt and new json formats we ensure uniqueness. As part of this change, support for UUIDs in OPS has been added.
As both the csv and file based methods now contain identical code, this logic has been moved into processor functions.
Documentation has been updated to draw attention to the requirement of ENFORCE_WHITELIST to actually enforce the configured whitelist. A server log message has been added to warn if the whitelist functionality is enabled but not enforced. The duplicate setting of 'whitelist' and 'white-list' in server.properties has been removed, leaving only 'white-list' being applied. I believe this was an error introduced with the addition of whitelist functionality in 111883e, that was subsequently fixed in 32cb5f4.
|
Testing Ops configuration. Fresh Ops configurationVars: 1.17.1 ( 1.7.6 ( 1.7.5 ( Update Ops configurationVars: 1.17.1 ( 1.7.6 ( 1.7.5 ( Testing 1.7.5 server with pre-defined
|
|
Testing mixed whitelist configuration (without enforcement)
Testing with remote whitelist file, and one launch override Logs: Result ( |
This significantly speeds up processing for large csv lists.
3e05807 to
831085b
Compare
itzg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refactorings look great. I did a quick test with OPS=itzg and WHITELIST=itzg,user2. ops.json looked right but whitelist.json ended up with itzg listed with ops structure:
[ { "uuid": "5cddfd26-fc86-4981-b52e-c42bb10bfdef", "name": "itzg", "level": 4 }, { "uuid": "5cddfd26-fc86-4981-b52e-c42bb10bfdef", "name": "itzg" }, { "uuid": "redacted", "name": "user2" } ]
The playerDataList variable was being re-used, and adding to whitelist after Ops processing.
|
@itzg good spot. Although not harmful (seems that option is ignored), it was re-use of the Making that local seems to have fixed the issue: |
itzg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjustment looks good. Thanks!
|
This is now merged to all the variants, tagged, and pushed |
|
Appreciate it! |
|
@Stealthii it there any way now to add player to the whitelist or ops list without call to playerdb API? |
|
You can still pass UUIDs directly with OPS or WHITELIST, which won't need
converted for 1.7.5 or later, or use OPS_FILE or WHITELIST_FILE with a
predetermined list.
If your server can't make the call out to playerdb, I'd recommend looking
up the player IDs yourself and adding these to the config. This way there's
no ambiguity with username swapping.
…On Sun, 30 Jan 2022, 08:45 Michael Ilyin, ***@***.***> wrote:
@Stealthii <https://github.com/Stealthii> it there any way now to add
player to the whitelist or ops list without call to playerdb API?
—
Reply to this email directly, view it on GitHub
<#1182 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHT4CENU6SLE3HYQYVCCCLUYT3DFANCNFSM5J2VVEDQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
This PR implements a few notable changes to the handling of ops and whitelist configurations, including:
OPS_FILEandWHITELIST_FILE)OPSand better handling of mixed configurationsDocumentation has been updated to clarify the configuration options, and draw attention to the
ENFORCE_WHITELISTvariable (with a warning being added to the logs when whitelist is enabled but not enforced).Detailed changes and rationale can be seen in the expanded commit messages.