Rate Limiter Roblox Seguro contra Spam de RemoteEvents
ESCOPO
Este prompt cria um sistema profissional de rate limiting para experiências Roblox que recebem muitas requisições do cliente via RemoteEvents ou RemoteFunctions. O resultado usa um modelo token bucket configurável por ação, permitindo controlar rajadas temporárias, taxa de reposição, punições progressivas e bloqueios temporários sem confiar no cliente.
Ideal para jogos com combate, inventário, lojas, habilidades, crafting, trocas, teleporte ou qualquer mecânica exposta por remotes. O prompt exige validação no servidor, limpeza de memória quando jogadores saem, logs opcionais para depuração e uma API clara para integrar o limitador aos handlers já existentes.
Basta informar a estrutura real do Explorer, os RemoteEvents usados e os limites desejados. A IA devolverá um ModuleScript Luau comentado, pronto para colar no Roblox Studio, além de exemplos seguros de integração e um roteiro objetivo de testes.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox Luau sênior, especialista em segurança de arquitetura cliente-servidor, escalabilidade e prevenção de abuso por RemoteEvents/RemoteFunctions. Gere um sistema de rate limiting servidor-autoritativo, baseado em token bucket, adaptado ao contexto real do meu jogo.
Antes de escrever o código, use o contexto que vou preencher abaixo. Se algum campo estiver ausente, não invente nomes de objetos nem assuma uma hierarquia inexistente: declare de forma objetiva quais valores precisam ser substituídos e use nomes de exemplo claramente marcados. Priorize entregar uma solução funcional e pronta para adaptação, sem fazer perguntas de acompanhamento.
CONTEXTO DO MEU JOGO (preencherei antes de enviar):
- Caminho/pasta dos RemoteEvents e RemoteFunctions no Explorer: [EX.: ReplicatedStorage.Remotes]
- Lista de remotes a proteger, tipo e finalidade: [EX.: AttackEvent - RemoteEvent - ataque; BuyItem - RemoteFunction - compra]
- Limite desejado por ação: [EX.: AttackEvent: 8 por segundo, rajada de 12; BuyItem: 2 por segundo, rajada de 3]
- Política ao exceder: [EX.: ignorar requisição, avisar em log, bloquear por 10 segundos após 5 violações]
- Sistemas servidores que já manipulam esses remotes e seus caminhos: [PREENCHER]
- Se devo usar DataStore, kick, banimento ou analytics: [PREENCHER; padrão: não usar]
- Versão/recursos específicos do jogo que precisem ser preservados: [PREENCHER]
O ARTEFATO PRINCIPAL DEVE SER exatamente um ModuleScript chamado `RateLimiter`, colocado em `ServerScriptService/ServerModules/RateLimiter`. Ele deve ser exclusivamente executado pelo servidor; não crie LocalScript, não coloque lógica de autoridade em ReplicatedStorage e não permita que o cliente informe seus próprios limites, timestamps, contadores, saldo de tokens ou status de bloqueio.
Escreva o ModuleScript Luau completo dentro de um único bloco markdown ```lua. O código deve ser pronto para colar no Roblox Studio, sintaticamente válido em Luau e extensamente comentado em português. Use `game:GetService("Players")` e uma fonte de tempo monotônica adequada, preferencialmente `os.clock()`, para calcular a reposição de tokens. Implemente uma API limpa e tipada, quando aplicável, contendo no mínimo:
1. Configuração por chave de ação/remoto, com `capacity` (rajada máxima), `refillRate` (tokens por segundo), política de log e parâmetros opcionais de bloqueio progressivo.
2. `RateLimiter:Check(player, actionKey)`, retornando uma decisão explícita e informações úteis, como permitido/negado, tokens restantes, motivo e tempo até a próxima tentativa válida. O estado deve ser independente para cada combinação jogador + ação.
3. Um método seguro para registrar violações e aplicar bloqueio temporário no servidor, sem kick ou DataStore por padrão. O módulo deve permitir callback opcional de auditoria/log, mas jamais expor dados sensíveis ao cliente.
4. Limpeza total dos dados de um jogador em `Players.PlayerRemoving`, além de uma estratégia simples para evitar crescimento de memória caso chaves de ação sejam desativadas ou jogadores saiam inesperadamente.
5. Proteção contra entradas inválidas: valide se `player` é um `Player`, se a chave existe na configuração e se os valores numéricos são finitos, positivos e coerentes. Falhas de configuração devem gerar `warn` útil no servidor, sem derrubar o jogo.
6. Segurança contra concorrência e reentrância: explique em comentários que cada callback de RemoteEvent é executado no servidor e que o handler protegido ainda precisa validar payload, distância, estado do personagem, permissões, preço, inventário e cooldowns de gameplay. Rate limiting não substitui validação de regras de negócio.
Após o bloco do ModuleScript, inclua uma seção curta chamada `Integração no servidor` com exemplos separados, também em Lua, mostrando como um Script servidor já existente deve requerer o módulo e chamar `RateLimiter:Check(player, "NomeDaAcao")` como primeira etapa do handler de cada RemoteEvent/RemoteFunction. Esses exemplos são somente trechos de integração: não crie um segundo sistema completo nem substitua handlers de gameplay existentes. Para `RemoteFunction`, deixe claro que o servidor deve retornar um resultado seguro quando o limite for excedido; para `RemoteEvent`, ignore a chamada e registre a tentativa conforme a política configurada.
Não use `RemoteEvent:FireClient` para comunicar detalhes internos do rate limiter, não use qualquer código de executor, não dependa de APIs HTTP, não armazene estado crítico no cliente e não implemente punições irreversíveis automaticamente. Não confie em argumentos enviados pelo cliente para identificar ação, custo ou permissão: o Script servidor deve escolher a chave de ação fixa correspondente ao remote que está atendendo.
Finalize com uma seção `Como testar no Roblox Studio`, em passos numerados, explicando como inserir o ModuleScript no caminho correto, como configurar os nomes reais dos remotes, como testar com Start Server e múltiplos Players, como disparar chamadas legítimas e spam, como observar Output/logs e como confirmar que requisições bloqueadas não executam dano, moeda, compra ou alteração de inventário. Responda em português do Brasil.
