Lodestone Licensing
Licenciamento para plugins Minecraft: emita chaves, controle onde o plugin roda e revogue quando precisar — sem derrubar o servidor do seu cliente quando a nossa plataforma cair.
O que é
O Lodestone Licensing responde uma pergunta por vez: este servidor pode rodar este plugin agora? A resposta não é um “sim” que qualquer um consegue forjar — é um documento assinado com Ed25519 que o plugin verifica sozinho, usando uma chave pública.
Nenhum segredo seu entra no .jar distribuído. Isso é por construção, não por disciplina: o plugin carrega apenas o identificador público do produto e uma chave que só serve para verificar.
Como funciona
- Você registra o plugin e recebe um Product ID público e imutável.
- Define a política: vínculo, limite de instalações, prazo, tolerância offline.
- Alguém compra o plugin no marketplace. A licença é emitida automaticamente.
- O comprador cola a chave no
config.ymle reinicia o servidor. - O SDK ativa, recebe o documento assinado, verifica e libera os recursos.
- O SDK renova sozinho, em segundo plano, sem travar a thread principal.
- Você revoga quando precisar — e a revogação vale na próxima verificação do servidor, não no próximo reinício dele.
O que protege — e o que não protege
Esta seção vem antes de qualquer tutorial de propósito. Um sistema de licença que promete mais do que entrega produz decisões de produto erradas.
| Protege | Não protege |
|---|---|
| Chave com ~98 bits de entropia: não se adivinha nem se enumera. | Quem controla o servidor pode remover a verificação do bytecode. Nenhum sistema impede isso. |
| Autorização assinada: descompilar o plugin não entrega nada que permita forjar. | IP e porta declarados são pista, não prova — chegam da própria máquina verificada. |
| Teto de instalações simultâneas, correto inclusive sob ativações concorrentes. | Um `.jar` modificado e redistribuído em fórum não é detectado pela plataforma. |
| Revogação imediata, com efeito na próxima verificação. | Nada impede alguém de comprar, baixar e republicar o arquivo. |
| Toda tentativa fica registrada com o motivo exato, visível no seu painel. | Ofuscação não é oferecida: ela não resolveria o item acima e tornaria o SDK impossível de auditar. |
O que isso significa na prática
.jar em algo inviolável, porque isso não existe.Em cinco linhas
LodestoneLicensing licensing = LodestoneLicensing.builder()
.productId("lsp_a1b2c3d4e5f6a7b8c9d0e1f2") // público, do painel
.licenseKey(getConfig().getString("license.key")) // do seu cliente
.dataFolder(getDataFolder().toPath())
.listener(new LicenseListener() {
@Override public void onAuthorized(LicenseResult r) { ligarRecursos(); }
@Override public void onDenied(LicenseResult r) { desligarRecursos(); }
@Override public void onGrace(LicenseResult r) { /* segue ligado */ }
})
.build();
licensing.activateAsync(); // NÃO espere por isto no onEnable()E, no caminho quente, a checagem é local e barata — lê um campo em memória, sem rede:
if (licensing.isAuthorized()) {
// recurso pago
}Requisitos
- Java 17 ou superior. Ed25519 entrou na plataforma no Java 15; Paper 1.18+ já exige 17. Abaixo disso seria preciso BouncyCastle — uma dependência pesada dentro de um plugin, com alto risco de conflito de classloader.
- Uma conta de vendedor aprovada no Lodestone.
- Nada além disso. O SDK não tem dependências de runtime, e o plano Free funciona sem configurar nada.
Quando a nossa plataforma cai
O servidor do seu cliente continua funcionando. O SDK guarda a última autorização assinada no disco e segue com ela até o fim da tolerância que você configurou — de horas a dias.
Isso não é um extra: é a diferença entre um sistema de licença utilizável e um que vira um ponto único de falha no servidor de outra pessoa. Uma indisponibilidade nossa não pode virar uma indisponibilidade de quem comprou o seu plugin.
Dá para ver isso acontecendo