You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add an element that can display an image that is not present in vanilla Minecraft, nor in any of the loaded resource packs. This element existed up to commit dd4b373, but was removed due to the packet length limit (which is roughly 32 KB).
A simple solution would be to send a URL that can supply the image, instead of sending the image itself. I am against this solution because I don't want to allow servers to make clients query 3rd party websites. The in-game chat has manual link opening confirmation for a reason.
It would seem that the only solution that's left is to implement a secondary data transmission form (a 2nd socket or custom packet reassembly on top of the plugin messaging channel). That is a lot of codebase to maintain for such a small feature, therefore I am not fond of this idea either.
A real solution might be to only allow specific URLs, or more specifically, only allow Imgur image IDs to be transmitted and construct the real URL client-side. I currently see no security risk in this (if someone can hijack your HTTPS traffic to Imgur you have bigger issues).
Whatever the case, if the image data doesn't get received together with the rest of the GUI data, it must be displayed asynchronously, aka not at the same time, but sometime in the future. This in itself causes a lot of complications. Whether to add this feature or not should be carefully considered.
The text was updated successfully, but these errors were encountered:
Add an element that can display an image that is not present in vanilla Minecraft, nor in any of the loaded resource packs. This element existed up to commit dd4b373, but was removed due to the packet length limit (which is roughly 32 KB).
A simple solution would be to send a URL that can supply the image, instead of sending the image itself. I am against this solution because I don't want to allow servers to make clients query 3rd party websites. The in-game chat has manual link opening confirmation for a reason.
It would seem that the only solution that's left is to implement a secondary data transmission form (a 2nd socket or custom packet reassembly on top of the plugin messaging channel). That is a lot of codebase to maintain for such a small feature, therefore I am not fond of this idea either.
A real solution might be to only allow specific URLs, or more specifically, only allow Imgur image IDs to be transmitted and construct the real URL client-side. I currently see no security risk in this (if someone can hijack your HTTPS traffic to Imgur you have bigger issues).
Whatever the case, if the image data doesn't get received together with the rest of the GUI data, it must be displayed asynchronously, aka not at the same time, but sometime in the future. This in itself causes a lot of complications. Whether to add this feature or not should be carefully considered.
The text was updated successfully, but these errors were encountered: