Pular para o conteúdo

Catálogo de demonstração. Produtos, criadores, preços e avaliações são fictícios. Recursos gratuitos podem ser adquiridos de verdade; itens pagos não são cobrados nem simulados. Ver o que já funciona

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

  1. Você registra o plugin e recebe um Product ID público e imutável.
  2. Define a política: vínculo, limite de instalações, prazo, tolerância offline.
  3. Alguém compra o plugin no marketplace. A licença é emitida automaticamente.
  4. O comprador cola a chave no config.yml e reinicia o servidor.
  5. O SDK ativa, recebe o documento assinado, verifica e libera os recursos.
  6. O SDK renova sozinho, em segundo plano, sem travar a thread principal.
  7. 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.

ProtegeNã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

O compartilhamento casual — passar a chave para um amigo — deixa de funcionar e fica visível. A redistribuição determinada continua possível, como em qualquer software. O Lodestone Licensing torna a primeira cara e a segunda rastreável; não transforma um arquivo .jar em algo inviolável, porque isso não existe.

Em cinco linhas

java
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:

java
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

O Playground tem um cenário de API indisponível que roda contra o serviço real e mostra exatamente o que o seu plugin receberia.