Bukkit

@tanjx

Really? My production server uses AuthMe and we've been able to log players just fine, whether they log in or not.

I'll take a look into it, but by the sound of it, AuthMe is loading before IP-Check, and this is a really simple thing to fix.

If you can open IP-Check's .JAR file (you can use 7-Zip or WinRAR), open the plugin.yml file in a text editor and add the following line to the bottom of the file:

loadbefore: [AuthMe]

Save the file and reload your server; this will allow IP-Check to log players before AuthMe. I'll be sure to add the to the plugin.yml for the next release as well. Thanks for bringing this up. :)

@pilvimaa I apologize for the inconvenience this issue has caused you. This is some sort of fluke that I haven't been made aware of so far and I'll do what i can to look into it.

That said, if I could get the following:

• A copy of your configuration would be nice (just to verify).
• What version of Java are you running and what type of database are you using?

Also, what specifically are the circumstances? Are all players being banned on login? New players?

In the meanwhile, I'd recommend downgrading to 1.5.4 until this issue is resolved.

The issue sounds like an issue with the PlayerLoginListener (the class where all of the login features function.) After reviewing the source code (and taking into account that all of the features have been disabled), there's only one piece of code that could be causing this issue:

if (player.isBanned()) {
    if (!db.getAltIPs(player.getName()).getBannedStatus()) {
        db.banPlayer(player.getName(),
                config.getString("ban-message"));
    }
} else {
    if (db.getAltIPs(player.getName()).getBannedStatus()) {
        db.unbanPlayer(player.getName());
    }
}

The above code is responsible for keeping bans in IP-Check in synchronization with Bukkit. There are no logic errors with it (that I can tell); If Bukkit has the player banned, IPC will ban them, and vice-versa if Bukkit has them unbanned. But going off of the information I've been given, this is the ONLY code the does any sort of banning with all other features disabled and with no commands being executed.

@Justmeitis

Check your database configuration settings. You may have a space in the dbName option or you may be missing a quotation mark.

@fungreenfox

What version of Java are you running?

@lskitto

UUID support is being pushed back for the immediate time being. Support was initially requested after I had already completely a good majority of the plugin rewrite. While I had hoped it would be a fairly simple implementation, further inspection indicates that switching to UUID would require a larger amount of work than I had originally thought.

That said, it's in the works, but it's not in 2.0.0. Expect it to be released with 2.1.0. :)

Probably should've posted this sooner; IP-Check 2.0.0 b2053 has been released to Bukkit and is awaiting approval. A lot of changes were made, and some have been pushed back to future builds. At the time of typing this, the plugin has been awaiting approval some 27 hours... So hopefully it's released soon! :)

The Default Localization Template (linked to at the top of the page) has been updated for v2.0.0. A list of changes made to the Localization Index will be made available shortly. It is very important that these changes be looked over by anyone using a custom Translation Index, as v2.0.0 changes several localization keys.

@pilvimaa

Interesting...

That means that a conversion would be possible. Thank you, pil. :)

@pilvimaa

Right, and that's sort of what I was leaning towards. But I've got some tests of my one I'd like to run first.

Thing is, as far as the Bukkit API is concerned, all player objects have a getUniquieID method which returns the UUID for the player (this is available for Offline Players as well, which fits our purposes quite nicely.) That said, there's no doubt that offline players generate some form of UUID. The real question is, though, as far as Offline Players are concerned, is that UUID persistent? Or does a new ID get generated when they log in? Assuming it's the former, then I can proceed to convert the entire plugin to interface with UUIDs, and only limit certain features of the plugin to Online Mode only (things like checking for players with different names but the same UUID.) I guess my main goal currently is that, whatever changes are made, the database back-end needs to work fully for both online and offline mode, with as little additional code as possible (checking for online mode in every method of the Database Controller could theoretically double the effective size of the code.)

Like I said, lots of stuff up in the air on this, but there's a good possibility it'll be included at some point.

@pilvimaa

(Word of forewarning, I'm answering this at 3AM; I'm rather tired and I haven't exactly done a large sum of research into the UUID system as of yet. Given that, a good portion of my response may or may not be based on my own understanding and assumptions. (TL;DR If I'm wrong about any I'm about to say, sorry. :) )

It's something to consider, yes, but it may not be implemented immediately.

The main concern is that IPC is intended for servers running in both online and offline mode. The server I maintain runs in offline mode, for example. The upcoming changes in 1.8 do mark a point of concern though, so that's not to say that the issue will be ignored. There will be plans for it in the future, and, given this, new features could be implemented which were previously impossible.

But, in retrospect, these new features would only be available to servers running in online mode. Granted, Online Mode is the recommended of the two modes, but I still prefer to have support for both modes (and since, as I said, my server is not online, there's a good chance this will remain my policy.)

That said, it's a definite maybe, but a lot of planning and work will have to be put into such considerations before anything is set in stone.

@dutchy1001

I myself wouldn't mind a country blacklist, either. Good suggestion!