Remove unsecure popup #205
YoyoNow
Lixfel
Label
Kein Label
Bug
Codeverbesserung
Einsteiger Freundlich
Idee
In Arbeit
Neues Feature
Prio A
Security Breach
Überprüfung notwendig
Verbesserung
Zu Beobachten
Kein Meilenstein
Niemand zuständig
3 Beteiligte
Nachrichten
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten
Keine Abhängigkeiten gesetzt.
Referenz: SteamWar/SpigotCore#205
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "ServerDataHandler" löschen
Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?
@ -132,6 +133,9 @@ public class Core extends JavaPlugin{if(Core.getVersion() < 17 && Bukkit.getPluginManager().getPlugin("ViaVersion") != null)new PartialChunkFixer();if(Core.getVersion() < 18)Das sieht mir falsch aus
@ -0,0 +8,4 @@public class ServerDataHandler {private Class<?> explosionPacket = Reflection.getClass("{nms.network.protocol.game}.ClientboundServerDataPacket");Field naming?
@ -38,0 +41,4 @@public Object modifyServerDataPacket(Object o) {ClientboundServerDataPacket clientboundServerDataPacket = (ClientboundServerDataPacket) o;try{o.getClass().getDeclaredField("c").setBoolean(clientboundServerDataPacket,true);Hier solltest du vllt dir das field cachen?
Statt direkter Reflection bitte die TinyProtocol-Klasse Reflection nutzen und den FieldAccessor als private statitc final speichern.
Was ändert das?
Kein Exceptionhandling, nur minimale Runtime-Reflection (der Aufwand ist vorher in der initialisierung), Konvention wie bei unseren sonstigen Reflections auch (Techhider, REntity, etc.).
ok
Hast du nicht gemeint, den Popup gibt es schon auf der Lobby, welche in der 1.15 läuft? Dann wäre diese Änderung hier sinnlos und muss stattdessen im BungeeCord stattfinden.
@ -0,0 +8,4 @@public class ServerDataHandler {private Class<?> serverDataPacket = Reflection.getClass("{nms.network.protocol.game}.ClientboundServerDataPacket");Du kannst hier direkt auf die Klasse zugreifen, da es das nur in der 1.19> gibt. Keine Reflection an der Stelle nötig.
In der 1.20 wird das sicher wieder geändert, ist sicherer jetzt schon es so zu haben.
zOnlyKroks hat eben durch kurzes testen es immer nur bei einem server switch erhalten nicht beim joinen.
Wenn sich in der 1.20 der Klassenname ändert, funktioniert dieser String aber genauso wenig. Daher macht hier schon für die 1.20 vorzusorgen überhaupt keinen Sinn.
Beim Serverswitch auf beliebige Subserver oder nur 1.19.1 Server? Nur falls nur auf 1.19.1 Server wäre diese Lösung hier korrekt.
Letzteres weiß ich nicht. und ersteres ok.
nur wenn auf 1.19.1 joinen.
@ -26,2 +27,4 @@public class ChatWrapper19 implements ChatWrapper {private static final Reflection.FieldAccessor<Boolean> accessor = Reflection.getField(ClientboundServerDataPacket.class, "c",Boolean.class);Kannst du es statt über den Namen über die Position machen? Also dass es das x. Boolean-Feld in der Klasse ist? Das macht das ganze Multiversionsstabiler.
@ -26,2 +27,4 @@public class ChatWrapper19 implements ChatWrapper {private static final Reflection.FieldAccessor<Boolean> accessor = Reflection.getField(ClientboundServerDataPacket.class, Boolean.class,0);Wurde das getestet? Weil ich glaube, dass das Feld vom Typ boolean.class (Primitive Klasse! Kleingeschrieben!) ist und das dann mit der Wrapperklasse fehlschlägt...
Schaut gut aus, ist das tested?
Jo, tut auch bei mir
Pull-Request geschlossen