Secure Roblox Admin Panel: Kick, Ban, Teleport, and Items
ESCOPO
Generate a complete administrative panel architecture for Roblox, aimed at experiences that need secure moderation and real-time operational control. The system includes kick commands, persistent bans with DataStore, player teleportation, and item granting, with permissions restricted to administrators configured by UserId or role/group.
The prompt requires a professional implementation with separation between the client interface and server authority. Every command requested through the panel is revalidated on the server, preventing exploiters from using RemoteEvents to ban users, obtain items, or perform administrative actions without authorization.
Ideal for developers who want ready-to-use Luau code to organize and paste into Roblox Studio, but need to adapt the result to the real structure of their own game, such as folder names, tools, existing RemoteEvents, inventory system, and teleport locations.
Conteudo
Prompt principal
Act as a senior Roblox Luau developer, specialized in secure multiplayer systems, scalable UI, and client-server architecture in Roblox Studio. Create a complete Administration Panel system for my Roblox game, with kick, persistent ban, teleport, and give item commands, ready to be integrated into Roblox Studio. Before writing the code, analyze the context below and use exactly the object names, Explorer paths, internal APIs, and conventions that I provide. If any essential data is missing, do not invent a specific integration: state an objective assumption, isolate it in a CONFIG section, and explain how to replace it. Context of my game (I will fill in): - Authorized administrators (UserIds, group/rank, or both): [PASTE HERE] - Current Explorer structure: [PASTE HERE] - Existing RemoteEvents/RemoteFunctions and their paths: [PASTE HERE] - Item/inventory system and location of Tools or function to grant them: [PASTE HERE] - Allowed teleports (SpawnLocations, Parts, PlaceIds, or custom system): [PASTE HERE] - Ban policy and default message: [PASTE HERE] - Name, theme, and expected UI behavior: [PASTE HERE] Implement the solution in layers, delivering ALL necessary files, not just isolated snippets. The minimum architecture must contain: (1) a server Script in ServerScriptService called AdminService, responsible for authorization, command processing, ban DataStore, auditing, and validation; (2) a LocalScript in StarterPlayer > StarterPlayerScripts or inside the ScreenGui of the panel in StarterGui, called AdminPanelClient, responsible only for the interface and sending requests; and (3) a ModuleScript in ReplicatedStorage called AdminConfig, with centralized configuration for admins, limits, allowed item catalog, and teleport destinations. If necessary, create and describe the RemoteEvents in ReplicatedStorage > AdminRemotes, preferably AdminCommandRequest and AdminCommandResult. Do not allow the client to create, freely choose, or execute privileged actions. The panel must allow selecting or entering the target player by username/display name, show the online player list, choose the action, and fill in the reason and applicable parameters. Implement the commands: kick (with sanitized reason), ban (persistent by UserId via DataStoreService, with reason, author, date, and an option for temporary duration if feasible), teleport (only to destinations pre-approved in the configuration), and give item (only items explicitly present in a whitelist in the configuration). For a banned player, block entry using Players.PlayerAdded and apply Kick with an appropriate message. If DataStore fails, handle it with pcall, log detailed warnings on the server, and adopt a safe policy explained in the code, without allowing silent data corruption. Security is a mandatory requirement: the server must be fully authoritative. Validate on the server the RemoteEvent sender, current admin permission, target, command type, required fields, maximum string length, dangerous characters, existence of the item/destination, and rate limiting per administrator. Never trust the client to define damage, currency, inventory, permissions, the author’s UserId, or the result of the action. Do not accept arbitrary Tool names or CFrames sent by the client. Use UserId for persistent data and authorization. Prevent administrators from performing actions on users with equal or higher permission level, when this rule is enabled in the configuration. Use RemoteEvent:FireServer only on the client and OnServerEvent only on the server, with minimal and structured arguments. Deliver the response in this exact format: first, a brief overview of the architecture and an Explorer tree with all the objects I need to create. Then, provide each complete file separately, clearly identifying the file type and the exact path where it should be placed. All code must be in markdown ```lua blocks, be valid Luau, complete, commented in Portuguese, and ready to paste. Do not use pseudocode, omissions like “add your logic here,” or unexplained external dependencies. Also include the minimal programmatic creation of the UI in case I do not have a ready ScreenGui, with open/close button, player list, text fields, action buttons, and feedback area. At the end, include objective instructions for testing in Roblox Studio: enabling API Services for DataStore in a published test environment, configuring administrative UserIds, testing with Start Server and multiple Players, validating kick/ban/teleport/item, checking server logs, and testing improper client-side attempts. Also explain how to manually unban a UserId safely, preferably through a server-side administrative function or a restricted maintenance tool.
