先作为主站备份 源站:https://my.toho.red

Introduction to Autowhitelist & My Research on Minecraft Whitelist

Before starting this article, let's talk about the autowhitelist project: this is a program that automatically adds MC server whitelist. The server owner can create questions for players to answer, and once the players reach the passing score, they will be automatically added to the whitelist, eliminating the need for manual review and addition. ~~Of course, essay-style questions still need manual review~~.

If you want to try it out as a guinea pig, you can take a look at the project's open source repository. There are pre-compiled versions available for download on the release page. After downloading, simply set it up and you're good to go. However, you still have to write the questions yourself.

So what prompted me to create this project? The reason is not grand at all, it's just that I'm too lazy to do manual reviews apparently laziness is the driving force behind technological development. Although the principle and reason of this plugin are not grand either, they don't have any sophisticated content, but I still spent a long time researching and developing a complete frontend and backend program. So let's talk about the entire development process below.

First, let's talk about the communication method between the frontend and backend. Initially, I wanted to use websocket for long-polling communication, but since I didn't have any relevant knowledge, I couldn't figure it out after researching for a while. So I turned to HTTP long-polling. However, using this method, I encountered another problem: message queue. Since long-polling cannot push messages to the client in a timely manner, a queue is needed to cache messages, and when the client polls, the queue is read and pushed. However, this problem couldn't be solved, no matter what solution I used, I couldn't guarantee stability, and long-polling required multiple times more resources to run, so I gave up this method and switched to socketio.

Although socketio is a wrapper library for websocket and theoretically easier to use than pure websocket, I still encountered a problem during the usage, a problem that I couldn't solve for nearly two days (as mentioned in the previous article). In the end, I was able to solve it with the help of a genius on V2EX. This problem seems to be the most difficult one during the development process, and after solving it, the development progress was rapid, and soon the entire project was completed not really.

With the connection method determined, the next thing to determine is the frontend and backend frameworks. Naturally, I used Flask and Flask-SocketIO for the backend, as these are the web frameworks I am most familiar with. However, I encountered a dilemma in the client-side. If I only need to receive messages, then a socketio library would suffice, but the problem lies in how to add players to the whitelist.

Since I have been using MCDReforged for a long time and I only know Python, I decisively chose to develop with MCDReforged. But during development, a big problem arose: the code in MCDR plugins is executed synchronously by default, which means that the next operation can only be performed after the code in the plugin is executed. However, because my plugin needs to maintain a long connection, MCDR cannot wait for my code to finish executing, so the thread will be blocked indefinitely and other commands cannot be executed. Although MCDR comes with a multi-threading feature, this feature is extremely imperfect and cannot close threads, which means that if the plugin restarts, there will be two threads connecting to the backend at the same time. Weighing the pros and cons, I decided to give up the MCDR platform and find another way: directly manipulating whitelist.json.

If I manipulate it directly, I don't need to consider multi-threading and other operations, nor do I need to worry about thread blocking. So I went further down this path and finally wrote the first product that can be used normally.

Not long after I finished writing it, I regretted it: I never considered using it for cracked servers. Since whitelist.json needs to store both player IDs and UUIDs, I hardcoded the method of obtaining UUID from Mojang's official API in the program. Although the UUID of cracked servers can be randomly written, the UUID of genuine accounts can also be used directly, but I'm afraid that some cracked player IDs do not have corresponding genuine UUIDs. It seems that an external program is not omnipotent, and an internal plugin solution is more reliable.

Although I don't know Java, fortunately, I found someone willing to cooperate. I believe that soon, there will be fabric and spigot versions available. I hope this project will continue to improve, after all, this is the first project I initiated with research direction and prospects.


Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.