Secure Admin Audit Log with DataStore for Roblox
ESCOPO
Generate a professional administrative audit system for Roblox, designed to record actions such as bans, kicks, teleports, granting coins, inventory changes, and internal commands. The script organizes events into serializable batches and saves them securely in DataStore.
The prompt requires authoritative server-side architecture, strict validation of permissions and received data, protection against request spam, and DataStore failure handling. It also guides you to provide the real structure of your Explorer, the existing RemoteEvents, and the administrative rules of your project.
Ideal for developers who need traceability, abuse investigation, and a persistent history of sensitive operations in Roblox multiplayer experiences.
Conteudo
Prompt principal
Act as a senior Roblox developer, specializing in Luau, multiplayer security, and persistence with DataStoreService. Create a complete, persistent administrative action log system in DataStore, ready to paste into Roblox Studio and adapted to the context of my game provided below. Before writing the code, consider this context that I will fill in. If any field is empty, adopt a safe convention, state the assumption objectively, and keep the system functional: - Name and location of the current administrative system/commands in Explorer: [PREENCHER] - RemoteEvents/RemoteFunctions already existing and their respective locations: [PREENCHER] - How the game identifies administrators (UserIds, group/rank, whitelist, custom framework, etc.): [PREENCHER] - Actions that must be audited (for example: kick, ban, unban, teleport, givecoins, setlevel, giveitem, mute): [PREENCHER] - Structure of the arguments for each administrative action: [PREENCHER] - Whether there is a custom system for coins, inventory, bans, or player data: [PREENCHER] - Desired limit of records per period/segment, if any: [PREENCHER] - Desired DataStore name: [PREENCHER] Generate ONE complete server Script, of type `Script`, to be placed in `ServerScriptService`. It must contain a clear internal API, preferably a local function or table called `LogAdminAction`, so that other server scripts can record events without depending on the client. Explain, before the code and in a few lines, how existing administrative scripts should call this API or how to integrate the call at the exact point where each command is confirmed by the server. If a direct integration between scripts requires a ModuleScript, do not change the main request: deliver the functional Script and explain a safe alternative with BindableEvent or the optional conversion to ModuleScript, without creating a mandatory dependency on missing code. The system must record, at minimum: unique event identifier, UTC timestamp in Unix format, UTC date, UserId and name of the administrator, UserId and name of the target when applicable, standardized action name, sanitized arguments, optional reason, server/jobId and placeId. Never record unnecessary sensitive information. Create a sanitization function that converts arguments into values serializable by DataStore, limits string length, table depth and item count, discards invalid types such as Instances, functions and userdata, and avoids saving excessive data. Implement a realistic strategy for DataStore limitations: do not perform an immediate write for every command. Use an in-memory queue, batch grouping, configurable flush interval, maximum queue size, and `pcall` for every persistence operation. Organize logs into segmented keys by UTC date and by segment/part, avoiding size limit violations. Use `UpdateAsync` to reduce the risk of overwriting concurrent records across servers. Include retries with simple backoff in case of failure, warning via `warn`, temporary retention in the queue when possible, and flush on shutdown using `game:BindToClose`. Do not attempt to guarantee absolute persistence during shutdown, but handle the scenario as well as the platform allows. Security is mandatory. The server must be authoritative: never accept from the client that an action occurred, who is an administrator, what coin value was changed, what item was given, or what target was punished. If my current flow uses RemoteEvent or RemoteFunction, demonstrate server-side validation of permissions, type, limits, target existence, and action rules BEFORE executing the operation and only THEN recording it. The log routine must not, by itself, grant privileges. Include rate limiting per administrator to prevent log spam and protect the script against errors caused by malformed data. Use current Roblox APIs, Luau typing when it adds clarity, consistent names, and helpful comments in Portuguese. Do not use `loadstring`, HttpService to persist logs, DataStore on the client, or pseudo-Luau code. Do not invent RemoteEvents, paths, or frameworks as if they existed; when you need an integration point, mark it clearly as configuration or adapt it to the context fields above. Your final response must contain: (1) a brief list of assumptions adopted; (2) the full, self-contained, commented Luau code, obligatorily inside a single markdown ```lua block; (3) precise instructions to create/place the Script in `ServerScriptService`, enable API Services in Studio for DataStore testing, adapt the administrator list, insert log calls into commands, and test in a published/test server environment. Do not omit essential snippets, do not deliver only examples, and do not split the code into incomplete parts.
