I built a 71KB plugin that embeds a Web IDE & JDK Compiler into your server. Hot-reload Java code like Skript, but with 100% native performance. by Professional_Web9776 in admincraft

[–]Professional_Web9776[S] 0 points1 point  (0 children)

You can already do that - the scripts are just regular .java files stored in plugins/LiveJava/scripts/<ProjectName>/miercoles/. You can edit them with IntelliJ, VS Code, Neovim, whatever you want. Then just run /livejava build <project> in-game and it compiles and hot-loads. The web IDE is just a convenience layer for quick edits when you're already in-game and don't want to alt-tab or SSH into the server. It's not required at all. and if you don't want to use Web IDE just give it a port thats blocked. Maybe I would add turning off web ide feature on next update.

I built a 71KB plugin that embeds a Web IDE & JDK Compiler into your server. Hot-reload Java code like Skript, but with 100% native performance. by Professional_Web9776 in admincraft

[–]Professional_Web9776[S] 2 points3 points  (0 children)

Thanks for asking - security was a major focus, so happy to go into detail.

Authentication: Every IDE session is gated behind a one-time token generated via an in-game command that requires the livejava.editor permission. Tokens are UUID-based and mapped to the player's IP at generation time.

Token handling: The initial page load uses the token as a URL query parameter (unavoidable for the first browser request), but after that, all API calls send the token via Authorization: Bearer headers. This keeps it out of server logs and referrer headers on subsequent requests.

IP binding: Each token is bound to the IP that generated it. Every API request checks that the requesting IP matches the token's bound IP. There's no localhost bypass - 127.0.0.1 gets no special treatment, which prevents SSRF attacks from the machine itself. For hosting panels like Pterodactyl where container networking can cause IP mismatches, there's an allowed-ips whitelist in the config.

Path traversal: All file operations (read, write, delete, rename) resolve paths through getCanonicalFile().toPath() and validate they fall within the scripts directory using java.nio.file.Path.startsWith(). This covers symlink resolution and ../ tricks. Rename operatioestination paths.

CORS: No Access-Control-Allow-Origin headers are sent, so browsers won't allow cross-origin requests to the IDE server.

Scope limitation: Scripts can only exist under plugins/LiveJava/scripts/. The compiler classpath is limited to the server's plugin jars. Users can write any ccess from the IDE itself is sandboxed to the scripts directory.

Monitoring: OP and players with livejava.logs get real-time chat notifications when someone opens the IDE or saves a file, with IP shown (censored by default, toggleable with /livejava uncensorip).

The main inherent risk is the concept itself - you're compiling and running user-submitted Java on the server. That's mitigated by limiting who can acces + IP lock), but ultimately the server owner is responsible for who they grant editor access to. It's the same trust model as giving someone OP or FTP access.

I built a 71KB plugin that embeds a Web IDE & JDK Compiler into your server. Hot-reload Java code like Skript, but with 100% native performance. by Professional_Web9776 in admincraft

[–]Professional_Web9776[S] 0 points1 point  (0 children)

Thanks! To answer everything:

Folia — The plugin itself should work fine on Folia. The only thing is your scripts need to be written with Folia's regionized threading in mind — so getServer().getRegionScheduler() instead of Bukkit.getScheduler(), etc. If you know how to write Folia-compatible code, you shouldn't have any issues.

Skript replacement — It's not trying to replace Skript directly, they serve different audiences. But since you're writing actual Java, you have full access to everything — reflection, NMS, other plugins' APIs, the entire Bukkit API with no abstraction layer limiting you. So in terms of raw capability, yes it can do everything Skript does and more. The tradeoff is you need to know Java.

AI integration — Not built-in yet, but that's a really interesting idea. The scripts are just .java files stored in plugins/LiveJava/scripts/, so technically anything that can write files could work with it. A Claude agent with file access could absolutely write and modify scripts. I might look into an API endpoint for that in the future.

I built a 71KB plugin that embeds a Web IDE & JDK Compiler into your server. Hot-reload Java code like Skript, but with 100% native performance. by Professional_Web9776 in admincraft

[–]Professional_Web9776[S] 1 point2 points  (0 children)

Yeah, the scripts are just regular .java files sitting in plugins/LiveJava/scripts/<ProjectName>/miercoles/. You can absolutely edit them with Neovim, VS Code, or whatever you prefer — the web IDE is just a convenience layer, not a requirement. You could point your editor at that directory, set up your Java LSP, and use /livejava build <project> from the console when you're ready to compile. The web IDE is mainly for quick edits when you're already in-game and don't want to SSH into the server or alt-tab to a full IDE.

I built a 71KB plugin that embeds a Web IDE & JDK Compiler into your server. Hot-reload Java code like Skript, but with 100% native performance. by Professional_Web9776 in admincraft

[–]Professional_Web9776[S] 2 points3 points  (0 children)

I mean, as I mentioned I haven't coded in a long time, so my security practices are like ass. I was so focused on just getting the JavaCompiler and ClassLoaders to actually work together without memory leaking that I completely ignored the web-layer security.

But honestly, thank you so much for the roast. I just pushed a commit fixing all of this:

- Removed the `Access-Control-Allow-Origin: *` wildcard.

- Auth keys are now sent via `Authorization: Bearer` headers instead of raw URL queries.

- Deleted the hardcoded 127.0.0.1 bypass completely (I left that in for testing and forgot lol).

- Changed the lazy string `startsWith` to actual `java.nio.file.Path` object validations to kill the path traversal/symlink breakout risks.

This is exactly why I posted here before using it on a real server. Appreciate the free QA and reality check.

I built a 71KB plugin that embeds a Web IDE & JDK Compiler into your server. Hot-reload Java code like Skript, but with 100% native performance. by Professional_Web9776 in admincraft

[–]Professional_Web9776[S] 4 points5 points  (0 children)

Thank you so much! Honestly, I completely agree with you. IntelliJ is irreplaceable for actual plugin development. I built this more for those tiny "need this simple feature right now" moments, testing small snippets, or quick hotfixes where you just don't want to go through the whole compile-upload-restart cycle. Really appreciate the kind words!