games647
Differentiate between Floodgate and Java players
In the Floodgate database, players are identified by their names. If you set autoLoginFloodgate to false, Floodgate players will be treated as cracked. And as a result, their name will be set to cracked in the database.
EDIT: so in other words, the database thinks that Floodgate and Java players are the same, if they have the same name.
I'm planning to differentiate Floodgate and Java players in the database, but it'll take some coding, and I'll also have to do some kind of backwards compatibility for existing players.
Originally posted by @Smart123s in https://github.com/games647/FastLogin/issues/696#issuecomment-1004973262
@Smart123s I think this is necessary to do, because FastLogin heavily depends on it and follows different really different program flow. Is there something I can help with? Maybe think of a database migration model? So we could do incremental changes.
The idea is to add another column to the database, called isFloodgate, similarly to isPremium. Honestly, I didn't really look into the database code, and its API implementation, but I think that it can be done by just copy-pasting isPremium code. (I actually realized that it's not that easy, I'll talk about it later).
The db migration is a harder topic. Creating a utility that would migrate every player to the new format on the first start of the server after the plugin was updated would be impossible. Currently, there's no a universal way to detect Floodgate players. That's why we need the change after all. Currently, the code sets isPremium to true for players who should be auto logged in.
A better implementation would be to migrate players when they join the server for the first time (after the plugin update). isFloodgate would be null for players that haven't been migrated. So if it's null, the plugin would check if the player is using Floodgate, and update the database.
But.... (this section only applies to servers that are not using a Floodgate prefix) The initial issue with the current implementation was that there were both Floodgate and Java players using the same name. And since they are different players, they'll need a different row in the db, ~~but they use the same name. Making isFloodgate a key in the db could solve this. But it'd look awful, and it'd require lots of changes do the db API.~~ EDIT: I've looked at the db, and the key is called UserID, which is unrelated to the player's name, so there can be two players with the same name in the db. And this problem (that I've described in the begging of paragraph) also makes migration harder. Let's assume we use the migrator that work on player joins. How do we decide if the old db entry is for a Floodgate or for a Java player? We simply can't, because of the problems I've outlined in the second paragraph.
Another migration approach could be to "delete" the old entry, and create a new one with the details of the currently joining session. But this also has drawbacks. For example, if the old db had a premium player, and someone migrates it using a cracked session, then auto login will be disabled for the premium players. And this also applies viva-versa. If an old cracked account is migrated to a premium one, they'll be able to use that account without a password.
I'm kinda stuck on ideas on how to do the migration part. I also don't know how much time I can spend on coding these days.
A better implementation would be to migrate players when they join the server for the first time (after the plugin update). isFloodgate would be null for players that haven't been migrated. So if it's null, the plugin would check if the player is using Floodgate, and update the database.
Yes that would be better.
But.... (this section only applies to servers that are not using a Floodgate prefix) The initial issue with the current implementation was that there were both Floodgate and Java players using the same name. And since they are different players, they'll need a different row in the db, but they use the same name. Making isFloodgate a key in the db could solve this. But it'd look awful, and it'd require lots of changes do the db API. EDIT: I've looked at the db, and the key is called UserID, which is unrelated to the player's name, so there can be two players with the same name in the db. And this problem (that I've described in the begging of paragraph) also makes migration harder. Let's assume we use the migrator that work on player joins. How do we decide if the old db entry is for a Floodgate or for a Java player? We simply can't, because of the problems I've outlined in the second paragraph. Another migration approach could be to "delete" the old entry, and create a new one with the details of the currently joining session. But this also has drawbacks. For example, if the old db had a premium player, and someone migrates it using a cracked session, then auto login will be disabled for the premium players. And this also applies viva-versa. If an old cracked account is migrated to a premium one, they'll be able to use that account without a password.
Doesn't Floodgate has an database for existing Floodgate players. Maybe we could those. Furthermore I think you shouldn't put too much work into the migration system. Maybe we could add an temporarily migration phase that would migrate existing player according to the old code, that could be disabled later. Otherwise I think it's better to drop it as a breaking change. Later changes could add a migration path back.