Permissions?

[randriusr]

I couldn't find any documentation on permissions for this plugin. I searched through the Modrinth post and here on GitHub, as well as on LuckPerms editor, but there were no permissions associated with this plugin. This is an issue because I can't grant permission to a specific group of moderators on my server without giving them the op permission.

[TheOnlySD12]

Hi randriusr,

I'm currently in the process of rewriting the plugin, and I've realized the importance of incorporating permissions. I'm contemplating whether it would be more practical to assign permissions individually for each command or to implement a single permission for all IPLogin commands. Your insights on this would be highly valuable. Additionally, I wanted to inform you that I'll be releasing snapshots for each feature I add or fix I make. I would greatly appreciate your input on these updates. Looking forward to hearing your opinions and suggestions.

Best regards, TheOnlySD12

[randriusr]

Hey TheOnlySD12,

To be frank, I don't see a compelling reason for the plugin to have distinct permissions for each command. While there might be some use cases out there, it ultimately depends on your preference - whether you want to keep it straightforward by assigning all commands to the same permission or separate them for potential future requests. My suggestion would be to cover both bases - have a primary permission for all commands and individual permissions for each command. While I don't have an extensive understanding of how MC permissions function, and I'm "relatively" new to Java, GitHub, etc., it's possible that the primary permission may not be necessary if other permission plugins operate similarly to LuckPerms. For instance, with LuckPerms, using something like IPLogin.* could grant access to all commands under the specified plugin.

Regarding suggestions, I have a few that might prove helpful if incorporated:

• Remove IP Command: I noticed that using *_/setip < name > _ isn't sufficient when I want to remove the IP for players who change locations during holidays, causing their IP to change. After they return, I'd like them to have the same IP associated with their username as before. While I could edit the name-to-ip.yml file to remove the asterisk and their username, having a dedicated command like /removeip < name > would be faster and more efficient. I made a modification to the source code and tested the /removeip command, which worked as intended. While I didn't test /setip < name > null**, having a separate command would be less confusing for some users. Here's a snippet of the code I edited, and I hope not to be judged - it was my first time working with plugin code:

        else if (command.getName().equalsIgnoreCase("removeip")) {
            if (args.length == 1) {
                if (sender instanceof ConsoleCommandSender || sender instanceof BlockCommandSender) {
                    nameToIPConfig.set(args[0], null);
                    getLogger().info("Removed IP for " + args[0]);
                    return true;
                } else if (sender instanceof Player player) {
                    if (sender.isOp()) {
                        nameToIPConfig.set(args[0], null);
                        player.sendMessage(Component.text("Removed IP for " + args[0], NamedTextColor.YELLOW));
                    } else {
                        player.sendMessage(Component.text("You do not have permission to do that.", NamedTextColor.RED));
                    }
                    return true;
                }
            }
        }

• Toggle IP Profiling Command: Introducing a toggle command for IP profiling would prove beneficial, especially when an admin wishes to manually apply IP protection exclusively to the staff. This feature would prevent all players from having their usernames linked to their respective IPs upon their initial login. During my search for the IPLogin plugin, I discovered several plugins designed for older Minecraft versions that operated differently. These plugins featured commands specifically made to "protect" staff accounts, a necessity in cases where servers utilized alternative authentication plugins such as nLogin or LoginSecurity as their primary authentication method. Players would often switch their usernames to staff names and log in, hoping to find out the locations where staff members had logged off. This situation had the potential to expose staff monitoring activities, leading players to use cheats like X-Ray with more caution. Thus, having a functionality to disable automatic IP profiling would be highly valuable, particularly in scenarios where protecting the Staff accounts is essential, while other players are protected by alternative Authentication plugins.

Those are my suggestions. Best of luck with rewriting the plugin!

Happy New Year, randriusr