Plugin pago do WordPress seguro
Eu quero criar um plug-in WordPress, mas também quero garantir que o plugin só pode ser usado depois de ter sido ativado com uma chave serial que deve ser única para cada domínio.
Qual é a melhor maneira de fazer isso assumindo:
- Eu tenho que dar o código-fonte real para os usuários e não pode ter um tipo de segurança VideoPress - que é apenas um wrapper JavaScript para o conteúdo real que vem do servidor do plugin.
- Eu quero garantir que um desenvolvedor novato em média PHP não seja capaz de contornar facilmente a segurança.
Opção 1 - Processar alguns dados no seu sistema
Eu não colocaria todo o processamento do plug-in em seu próprio servidor, mas escolha uma ou duas funções vitais e mantenha-as hospedadas em seu sistema. Em seguida, solicite uma chave de API para cada site que use o plug-in para que eles possam se comunicar com seu servidor.
Opção 2 - Criptografar dados armazenados e exigir uma chave de descriptografia hospedada
Outra alternativa é uma configuração básica de criptografia - este é na verdade um sistema com o qual venho brincando por um tempo, eu simplesmente não me preocupei em implantá-lo em nenhum lugar ainda. O código em si (para permanecer fiel à GPL) é todo texto simples, exatamente como você esperaria. No entanto, todos os dados armazenados (valores padrão, configurações de plug-in, etc.) são criptografados antes de serem salvos no banco de dados. O truque aqui é que o plug-in no sistema remoto não tem a chave de descriptografia - para descriptografar os dados, ele precisa postar sua chave de API no sistema, que então responde com a chave de descriptografia. Isso pode ser armazenado em um transitório (opção temporária) por um determinado período de tempo antes de ser liberado - dessa forma você não tem um site atingindo seu servidor a cada 2 segundos durante o tráfego pesado.
As desvantagens dessa abordagem podem, no entanto, superar os benefícios (e é por isso que ainda não a implementei em nenhum lugar). Primeiro de tudo, um programador experiente pode capturar a chave de descriptografia e, em seguida, eles não precisam mais do seu servidor. Ou eles poderiam simplesmente liberar todos os ganchos de criptografia/descriptografia e executar em texto simples. Essa é a vantagem do código aberto para o usuário e a desvantagem para o desenvolvedor que deseja distribuir um sistema livre, mas restrito.
A outra desvantagem é a dependência do seu servidor. Armazenar uma chave em um transiente elimina parte do peso do seu servidor ... mas se o seu site ficar inativo por uma ou duas horas, então todos os sites usando o seu plug-in desce por uma ou duas horas, a menos que você planeje algum tipo de desativação graciosa. Além disso, isso significaria que você teria que manter esse servidor funcionando indefinidamente se as pessoas continuassem usando seu sistema.
Opção 3 - Limite os recursos da versão "gratuita"
Uma última opção, e uma que estou trabalhando ativamente para usar, é dividir o conjunto de recursos e a funcionalidade do seu plug-in. O núcleo do sistema (interface do usuário, recursos básicos, etc) está disponível gratuitamente sem registro. Para recursos mais avançados, os usuários precisam registrar sua cópia, obter uma chave de ativação e, em seguida, inserir essa chave na interface do usuário para concluir o processo - o plug-in verifica com seu servidor e faz o download de "complementos" adicionais adicionais para o sistema .
A desvantagem aqui é que, uma vez baixado, todo o código agora fica no site do usuário e, sob a GPL, eles ainda podem redistribuir o pacote completo. A vantagem é que ela depende apenas do sistema uma vez e não requer nenhum tipo de suporte de download/processamento de longo prazo.
De qualquer forma que você decidir seguir em frente, você vai ser atingido com a manutenção de algum tipo de API externa em seu servidor ou fornecendo a fonte completa do sistema para seus usuários. Se você mantiver alguma funcionalidade no seu sistema, você quase tem que garantir 100% de tempo de funcionamento para valer a pena. Se você for fornecer a fonte completa, não há como (sob a GPL) impedir que outra pessoa redistribui seu sistema.
Você não pode ocultar o código fonte dos usuários do WordPress, nem pode limitar a redistribuição do seu plugin devido a implicações de licenciamento.
Você está criando um derivado do WordPress com o seu plugin e seus usuários têm o direito de obter a fonte dele e de redistribuí-lo livremente (veja as quatro liberdades no software livre ).
Supondo que o WordPress seja licenciado sob a GPLv2 e você tenha clientes fora dos EUA, você deve lidar com as implicações de uma violação da GPL que possa ter em seu produto ("protegido").
Você está tentando implementar um bloqueio de fornecedor para seus usuários.
A única maneira de ter um plugin distribuído que possua uma licença segura que qualquer programa decente não pode hackear é rodar a funcionalidade principal do plugin em seu próprio servidor, como o Akismet. O usuário deve enviar uma solicitação ao seu servidor que contenha sua chave de licença. Se a chave fizer check-out, execute o código-fonte e envie os resultados de volta.