games647 / FastLogin

Checks if a minecraft player has a valid paid account. If so, they can skip offline authentication automatically. (premium auto login)
https://www.spigotmc.org/resources/fastlogin.14153
MIT License
498 stars 121 forks source link

Name changes not handled properly #145

Open null321-jared opened 7 years ago

null321-jared commented 7 years ago

When users with Minecraft accounts (premium) change their name, it requires them to register again. This is a problem for two reasons. First, my settings in AuthMe limit the amount of times a user may register, locking them out. Second, my settings should result in that not being needed.

I have all of these relevant settings enabled (true):

It's possible that FastLogin is conflicting with AuthMe and never successfully registering the users due to the IP limitations.

I am using FastLogin version 1.10 from the build server 5 days ago.

null321-jared commented 7 years ago

Do you have any idea why this is happening so I can try to look into it?

games647 commented 7 years ago

I think it's because the statement here: https://github.com/games647/FastLogin/blob/master/core/src/main/java/com/github/games647/fastlogin/core/AuthStorage.java#L225

doesn't correctly matches the old result. I although I did multiple tests and it seemed to work fine.

null321-jared commented 7 years ago

It also may have to do with AuthMe, because it happens once the user reaches the IP limit. I want to limit cracked accounts to 2 per IP, but premium name changes eat that up very quickly..

SeruhioX commented 6 years ago

Currently my premium users do not stop complaining that when they change his name, they do not auto-login. They do ask for the password, and I have to run "/premium" to each of them.

SeruhioX commented 6 years ago

Some news? It's so important for me, many users for day complain about this... And I must have to run /premium for every one.

Srborjaa commented 6 years ago

I have also the same problem in my server, I have an average of 100 users in it, and I think you could understand that listening complainings about this problem is not so good.

SeruhioX commented 5 years ago

Any news about this? it's still happening

Apparently it happens when a player changes his name and then returns to his previous nickname

Srborjaa commented 5 years ago

imagen

LoneDev6 commented 4 years ago

Hey guys is this plugin working or not? I need to move my server from premium to offline mode and install this in order to allow both cracked and premium to join. But reading these issues is not a good start

null321-jared commented 4 years ago

Hey guys is this plugin working or not? I need to move my server from premium to offline mode and install this in order to allow both cracked and premium to join. But reading these issues is not a good start

Well I have not noticed a fix. The easiest way to fix this issue is to set authme to unlimited accounts per IP, but that can be abused.

7wOv6ySCjo commented 4 years ago

Is there any news about this? @games647

Victorsueca commented 3 years ago

Bump, I think we just stumbled upon this issue on a server I'm helping with. We're using FastLogin with Bungee and AuthMe, everything works fine until a premium user changes their username, the user then gets the new nickname registered as a new account with AuthMe, or so it would if users were allowed to register more than one account per IP, which in our case, they aren't.

We found two workarounds for this issue, but we are unable to implement these in our production server because both open up a gate for abuse by players.

  1. Raising the maximum amount of registrations per IP on AuthMe. This would prevent FastLogin from hitting the max accounts per IP so easily, but still leaves the old account with the old nickname in the database and assigned to the user's IP. It also potentially allows all users, both premium and cracked to abuse multi-accounts.
  2. Setting respectIpLimit to false. This would allow FastLogin to ignore if the user has already hit their registration quota for their IP. However the implications of this are similar to raising the max amount of registrations per IP, but it would limit the potential for abuse to users who own a premium account. It still leaves the old entry in the database, and it still allows people who own two premium accounts, or people who have registered a cracked account but also own a premium account, to abuse multi-accounts.