There has been a large amount of discussion about a server transferring mods to the client rather than manually downloading them. This has been marked as never going to happen due to security issues and the issue of creating a secure repo.
What if the server could send a description of a mod to the client using a very specific protocol. The server could send texture files, a description of any 3D models for mobs or blocks and a description of any custom menus or buttons for the HUD. This is basically all that the client really needs to function on a modded platform. The rest can be handled by the server. This way, all that is transmitted by the server is descriptions rather than actual Java code for execution. This nearly eliminates the security risk.
An API could be created for plugin development that people could register their, textures, custom 3D models, custom entities, and custom HUD elements with. Then the server, when the client joins reads from that API and sends the data to the client. The client can then parse that data and build the real Minecraft objects for the person.
Of course this would be limited, mods like GPL Shaders couldnāt be downloaded like that. The initial connection to a server would take a while. The client would probably save this mod data from the server, check if it has changed each time it connects and only downloads the info again if needed to save time connecting on any subsequent sessions.
What do you think? I know that this would be complicated and hard to do, but I do wonder if it is possible.
The Minecraft protocol already supports custom plugin channels, so something like this doesnāt have to be included in Sponge itself. Have you considered implementing this yourself as a mod or plugin? (assuming youāre a developer, if not then maybe someone else wants to.)
Either way, every client using this would need to have a mod installed, so personally I think this would make a good example of a powerful Sponge plugin.
Problem is that there is a limited amount of content that can be loaded after the game has initialized. Blocks, Items etc. are loaded in the initialization phase of the game and therefore new ones cannot be defined after this point.
Even if this is possible, a client will have to have a mod in order to accept block definitions from the server so is not ideal for most vanilla players.
@Hidendra I am a developer, if this would be possible I think it would be worth trying to make.
@bdubz4552 So do I, kind of a nagging feeling at the back of my brain.
@simon816 Ideally, I could implement some way to define blocks in real time or find some other workaround. Also, yes, both the server and the client would have to have this mod and all the mods that the server has must support it. It is not an ideal situation. I have thought of patching into the Forge API to get some of that info, but if the majority of the mods are to work, they would have to implement the mods API as well. That is probably the biggest problem with this.
Basically if you want something like this you will either need to rewrite a large portion of forge as well as probably modify existing mods to support it.
Alternatively use something like Technic Launcher
@progwml6 I am a developer, not a server owner / player, I was looking into doing something such as this. I am not looking for plugin packs, that is what I am trying to avoid, servers being limited by the popular packs out there that normal minecraft players never get to play large scale multiplayer on custom packs that could be awesome but just donāt get enough attention so no server owner bothers with them.
Realize that the server/client has special protocol designed for (hint hint) CustomPayload. Data sent would need to be assembled client side, but the server sending is easy.
Iāve seen a lot of this forum posts, A LOT.There is the security issue,and some other issues with this.But(not butt) it would be awesome if sometime in the future we get mods that behave like plugins with server-client side problems!
Why send anything executable, could it not be setup so as to send nothing but configurations, definitions, and pictures. One would need to send the model files, textures and definitions of any costume mobs, the config and texture of any guiās and the definition (Just model and properties) and the texture of any new blocks. With just this much info a client side mod designed to interpenetrate all of it could easily replace at least 2/3 of the current content adding mods.
This is what makes me think someone will find a back door. Ever heard of Bash? Its the command line used most commonly on not-Windows machines. The shellshock bug was sitting silently in Bash for many many many years, and while we think the system will work fine, I am a skeptic and have to question everything.
In case youāre like āWhat is this āShellshock bugā you speak ofā, hereās a video I thought explained it well and not incredibly technical about it: Shellshock Bug Video
I am well aware of shell shock, the issue there was the system was allowing data to be executed as code. This is preventable, if you think sql injection is the same deal: data is executed as code. How do we prevent sql injection, we sterilize data, such that even if it does get executed it is recognized as data not code.
Our solution could be even simpler: no remote code execution at all and sterilize incoming data by using a sterilize-able data format like sql for the properties of sent objects (or even an obscure plane text format like yml). Beyond this we donāt allow access to any subs or functions directly; we send properties only from the server, not a script.
The only thing for a mob received from the server would be a name, MobID, and model; for a block the same thing: a localized name an ID (or whatever they are now), a āGUI IDā if required, and a texture file name and location (along with the texture file itself) ; and for guiās: a āGUI IDā (for reference to the block they belong to), a definition of the locations of slots and buttons, and an image file within the texture pack. The buttons and slots would all be handled server side, the client just sending āCUSTOM GUI BUTTON PRESSā packets and standard inventory change packets back to the server for handling.
Notice that nothing sent to the client need ever have access to code, nerveless ever be run itself. Everything is handled server side, and if we are careful and sterilize all of that data and write our data parser such that nothing be ārunā this could be viable. Just make sure to escape any semicolons before interpreting the data and all should go well.
Iām not trying to compare this to Bash, Iām trying to put it side by side with the shellshock bug, point being that exploits can be hiding silently inside.
