ChangeSkin icon indicating copy to clipboard operation
ChangeSkin copied to clipboard

/setskin not working, MySQL errors, and more

Open bob7l opened this issue 6 years ago • 19 comments

What behaviour is observed:

Nothing appears to be working after updating. There is just a massive amount of problems. Prior to updating to 3.0, everything worked perfectly.

  1. Using /setskin appears to no longer do anything. Your skin never changes.
  2. There's no 429 handling? If the plugin receives a 429 error, it seems to just give up rather then trying in X minutes, or trying another source.
  3. The plugin is attempting to insert records that already exist.. https://pastebin.com/K9YvFXWN

There's clearly an issue with MySQL handling in version 3.0 https://i.gyazo.com/a75925397abd1a321951c5d4f7339aa8.png

What behaviour is expected:

For /setskin to change skins, 429 errors to be properly handled rather then ignored (Based on observation, have not checked the code), and for one one record per UUID to exist in my table.

Steps/models to reproduce:

I just use the plugin on my Bungeecord instance, and one of the spigot servers in the bungee network. I also use MySQL rather then SQLite

Plugin list:

Essentials, WorldEdit, WorldGaurd, Protocollib, NoCheatPlus, AAC

Environment description

Bungeecord, and only one of the spigot servers in the network use this plugin. The server version is 1.8, and the Bungeecord version is always within a week of the latest bungeecord release. The server is hosted on a dedicated machine, with a local MySQL instance. Server is also in Offline mode

Plugin version or build number (don't write latest or the build number with #):

3.0

Error Log:

https://pastebin.com/K9YvFXWN

And the HTML 429 stacktrace is pretty self explanatory

Configuration:

https://pastebin.com/mHu6vw52

bob7l avatar Mar 15 '18 17:03 bob7l

Update to a dev-build please. You are 43 commits behind with version 3.0.

Duplicate entry

Fixed after multiple tries (Next time I should make a branch for this) and with a lot helpful of some users. Commits affecting this: c47113c3af77c53104714f03ccc30cd0168ab260 a95906f959fd44590f01fbf2b80a7b691e7e89ee 61cc473cd4da1dddb674b0d3d068c82ad8eedd68 b6f1779a9014683d15c1dfc512751fbf99c88336 11ae5863b988cd542ed1a18b1600925422498bf2 59b337d3c6027fb8f3bda90164142e6daecc053f 6125c5648ad412cdc4994f349fdf0d91d11bb063 fbfdfbd2c7708008e4907d0f49b022606779c59d

429 errors handling

This should now be handled better with more logging messages to the user instead of just logging it.

games647 avatar Mar 15 '18 18:03 games647

It appears to have worsened. Now i only get "UUID was successfull resolved from the player name"

You should probably put "successfully" too

Using build #9​4 and the same database + table I've been using since initially using this plugin. Should i reset the database?

There's also no exceptions to be found. I've also noticed for whatever reason the command /setskin is NOT logged to latest.log.

bob7l avatar Mar 17 '18 16:03 bob7l

https://pastebin.com/WmLNEfiG

I found exceptions in the bungeecord log. The table is just screwed up behold repairing so I'm going to reset it later tonight when my traffic dies down.

I'll update you on whether or not a table reset resolves my issues.

bob7l avatar Mar 17 '18 17:03 bob7l

You should never reset a single table. Only both if you really need it. That exception means that the same got requested too often within one minute.

games647 avatar Mar 17 '18 17:03 games647

Please post the complete BungeeCord log.

games647 avatar Mar 17 '18 17:03 games647

Still broken: https://pastebin.com/mEueZt5r

You're clearly inserting already existing values instead of using UPDATE.

bob7l avatar Mar 22 '18 19:03 bob7l

:D I already know that. It's a race condition with multiple saves. I still need the complete log please.

games647 avatar Mar 22 '18 19:03 games647

Giving you the complete log will compromise my users IP's. The only errors in the log are the one provided, and the insert on existing values only happens sometimes on joins it seems. There are 0 errors other then that.

Rundown:

  1. I join the server with the username bob7l. My skin is properly set to the bob7l skin and my data exists within the MySQL.

15:56:21 [INFO] [bob7l] <-> ServerConnector [rustv2] has connected 15:56:21 [FINE] [ChangeSkin] Applying skin for bob7l 15:56:21 [INFO] [bob7l] <-> DownstreamBridge <-> [lobby] has disconnected

  1. I then execute /setskin Notch. It says with a green message the UUID was resolved successfully and nothing more. My skin still remains the same, so i exit and rejoin. Still the same skin (instant-skin is disabled in my config).

  2. I then execute /setskin bob7l Notch from the console and get "UUID was sucessfull" followed by "Skin was changed. Relogin to see the changes".

  3. I re-log into the server and still have the exact same bob7l skin.

Zero errors during the whole process. I just reset my tables for SkinData and preferences today and still nothing. I am using build #99.

My assumption is it's not reading from the MySQL correctly and using my default skin no matter what.

Here is the data for bob7l:

https://i.gyazo.com/7f7e6fb40ca64b0e5f41d33561d68643.png https://i.gyazo.com/c7ed030f05900d02eb3c2acda241a968.png

"Notch's" skin URL: a116e69a845e227f7ca1fdde8c357c8c821ebd4ba619382ea4a1f87d4ae94 "Notch's" UUID: 069a79f444e94726a5befca90e38aaf5

bob7l's UUID (preferences): e07381471d993189bd5081d8355c25f8 bob7l's skin URL: 88e8b7798bd67ec8710f14c642a6c88df57ef46badef39ceb3b317da53b6045 bob7l's UUID inside skinData: cc45fc40168b4ca996f665235c713209

After i relogged, it seems it set my skin back to bob7l because now my target skin points back to my actual account rather then notch.

bob7l avatar Mar 22 '18 20:03 bob7l

/setskin also appears to have a permanent cooldown. "Please wait, You cannot change your skin so fast" 8 hours later. My cooldown: 600

Also another thing i just realized. I never got a cooldown before. I believe the reason i got it this time is because i used the console to execute the setskin.

bob7l avatar Mar 23 '18 03:03 bob7l

I am able to set the skin through the console using /setskin bob7l Notch. The skin sets fine (Although i do not visually see it due to having instant change off). When i relog however, the skin is set back to the default bob7l skin by the BUNGEE instance.

bob7l avatar Mar 23 '18 04:03 bob7l

Giving you the complete log will compromise my users IP's.

That's a valid reason. Why don't you told me that earlier. You could easily remove the IP addresses: sed -r 's/[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}/CENSORED/g' *.log It just complicates the things a lot if I cannot see the context.

Rundown: [...]

What you are describing here is different bug... Do you tried to execute it from the Spigot or the Bungee console?

/setskin also appears to have a permanent cooldown. "Please wait, You cannot change your skin so fast" 8 hours later. My cooldown: 600

Fixed now. The number was accidentally in minutes.

When i relog however, the skin is set back to the default bob7l skin by the BUNGEE instance.

You mean from default skins or using restore skins?

Please keep tickets independent from each other next time. It's easier to isolate the details.

games647 avatar Mar 23 '18 11:03 games647

BTW What are your BungeeCord plugins, because I cannot reproduce it with ChangeSkin installed alone on it?

EDIT: Could you also try it with an empty blacklist? Maybe there is an issue.

games647 avatar Mar 23 '18 11:03 games647

I confirmed the issue ONLY occurs with "bukkit-permissions: true". I've tested this on a test server with zero other plugins.

Bungee version; #1​30​5 Spigot version: 1.10.2-R0.1-SNAPSHOT, And tested on 1.8

Using LuckPerms-Bukkit-4.1.25 and tested latest PEX too

bob7l avatar Mar 28 '18 05:03 bob7l

[23:09:35] [Server thread/INFO]: bob7l issued server command: /op bob7l [23:09:35] [Server thread/INFO]: [bob7l: Opped bob7l] [23:09:37] [Server thread/INFO]: Incomming message: 1522217377122 [23:09:37] [Server thread/INFO]: ChangeSkin [23:09:37] [Server thread/INFO]: bob7l [23:09:37] [Server thread/INFO]: Channel:PermissionsCheck [23:09:37] [Server thread/INFO]: rowId: 1 [23:09:37] [Server thread/INFO]: encodedData: eyJ0aW1lc3RhbXAiOjE1MjIyMTM3NzM4NTMsInByb2ZpbGVJZCI6ImNjNDVmYzQwMTY4YjRjYTk5NmY2NjUyMzVjNzEzMjA5IiwicHJvZmlsZU5hbWUiOiJib2I3bCIsInNpZ25hdHVyZVJlcXVpcmVkIjp0cnVlLCJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6Imh0dHA6Ly90ZXh0dXJlcy5taW5lY3JhZnQubmV0L3RleHR1cmUvODhlOGI3Nzk4YmQ2N2VjODcxMGYxNGM2NDJhNmM4OGRmNTdlZjQ2YmFkZWYzOWNlYjNiMzE3ZGE1M2I2MDQ1In19fQ== [23:09:37] [Server thread/INFO]: encodedSignature: A//ftEjFjCHV+IV0f24j+RlmUvwsD9ljuyFbfQMzUgIgl6A+Ys0D06MiVmPD7OJa3BUDICHCgIDTa77jCf4M2IduB4l+2H0GLnEzirbvx66HNPeb3E7eehEtcFKIb4c8GHbW0CZQQaa++YPRD4JEniEM/8hPOPx2Vyn2JHNrKnksOhRr/cwB8bC4jEkvYmsIrW421O27thoMSp0NeWPElieZwyq9Cm57RrmRjguvVWGM8wC9bylzpN+jAyUrYa6qSgRgc4TW4lj0wjnikBjb2TVq62ZjyVNFkH+pQy4+pjstKoV6Z0S2yspxNjpIAURgipeuincSYnzHuCX0h8XykhWCWAtJ4qKKULc2uVoqsOfqc1YZdq84OPqSfMzE+6I0acDv0mN2qUxDyRmI0FH1AO9fW5pBluRRLjSqvsaUpz7hCHRy8DzVm10r/wcg9lirDTXyWRsiZcuABQOhDZ+G3qSu8T7w3YFLyAsF/L8oJtSAEZkqkofHBLxDQkL2/RXAbKUanqMcQZEc37sCRyvuX80mt39RMYX1GazihzQxLHAKhPv3rOfuVrC4/uOXonKAI9C2/Kpv9Ws0UDtCmXms2rrcHHS65Oa8YvdJJNaCBrOzHX/bs1DJo1w3K33beUi0E3FNXoT173QjNIzdOjvMw8YSesEvOZK2eJto9+dZZoc= [23:09:37] [Server thread/INFO]: receiverUUD: e0738147-1d99-3189-bd50-81d8355c25f8 [23:09:37] [Server thread/INFO]: skinPerm: false [23:09:37] [Server thread/INFO]: isOp: false

This is listening to the plugin channel on the spigot server and printing all the data. bob7l is op and it still says isOp: false.

bob7l avatar Mar 28 '18 06:03 bob7l

BTW: Never use #Number it's used to reference to other tickets.

You are misunderstanding something here. The OP status is not bound to Bukkit, it's bound to BungeeCord that why it's always false.

Using LuckPerms-Bukkit-4.1.25 and tested latest PEX too

If you are already using LuckPerms, why don't you use the BungeeCord module of it. This way ChangeSkin doesn't have to worry about permissions forwarding.

Still some open questions:

Do you tried to execute it from the Spigot or the Bungee console? Could you also try it with an empty blacklist? Maybe there is an issue. [In combination with your newer answer maybe a combination of both]

What about the response. Do you checked if it it response with a successful response too?

games647 avatar Mar 28 '18 10:03 games647

I've tried with every configuration combination, that includes blacklist being an empty array.

I believe I figured out the problem.

When i join my hub server, I am able to /setskin perfectly and the Bungee server actually receives a PluginMessage from ChangeSkin. When I go into another server using /server survival I can no longer use /setskin and if i have "bukkit-permissions" DISABLED I'm able to set the skin, but the only message it gives me is the UUID was resolved. Also, in the survival server with bukkit-permissions ENABLED, the Bungee instance of ChangeSkin never even receives a plugin message from the spigot ChangeSkin whereas in the hub it does.

Bungee (Skin) -> Lobby (Skin) -> Survival Server (No skin)

bob7l avatar Mar 28 '18 18:03 bob7l

Could you check if ChangeSkin is installed in all Spigot servers and it correctly detected BungeeCord. ChangeSkin only listens to plugin messages if BungeeCord is enabled.

games647 avatar Mar 29 '18 11:03 games647

why dont u just put dev build on spigot every month? (genuinely curious)

Spikey101 avatar Mar 30 '18 18:03 Spikey101

@Spikey101 I only want to release well tested version to Spigot.

games647 avatar Mar 31 '18 14:03 games647