Estou perplexo com uma solicitação do meu gerente. Eu trabalho para uma pequena startup e desenvolvemos um aplicativo da Web por uma taxa fixa com um contrato de manutenção para uma empresa MUITO maior. Conhecendo histórias de horror sobre como as grandes empresas pagam suas contas apenas no último segundo, decidimos que gostaríamos de nos proteger, licenciando esse aplicativo da Web de uma maneira que, se não recebermos o pagamento, o software não funcionará mais.
Já vi isso antes em aplicativos de desktop, mas será um aplicativo da Web que eles hospedarão internamente e não poderão ser acessados pela Internet.
Qual é a melhor abordagem para fazer isso, gostaríamos que ela tivesse uma pequena área ocupada e gostaríamos da capacidade de renovar a chave de licença que eles distribuíram.
Alguém fez algo semelhante? Estamos completamente fora de nossas mentes? Alguém tem alguma sugestão melhor?
fonte
Respostas:
Existem várias maneiras de implementar algo assim, mas aqui está uma que não deve ser muito difícil de fazer:
Você precisa de um site disponível ao público em algum lugar que hospede um arquivo contendo os hashes das chaves de licença que foram incluídas na lista negra. A decisão de como você gerencia esse arquivo é sua, mas o arquivo em si só precisa ter um hash por linha.
Então, de forma recorrente, seu software inicia o download desse arquivo (a maioria dos idiomas do servidor fornece isso) e, em seguida, procura o hash da chave de licença instalada. Se for encontrado, o aplicativo sabe que deve morrer até que a lista negra seja removida.
MD5 ou similar mais um segredo deve ser suficiente para isso. Você pode ficar mais sofisticado e pedir ao aplicativo que envie a solicitação para o seu site e procure-a em um banco de dados em tempo real, mas o arquivo (pelo que eu suponho que seja uma lista curta) permanecerá pequeno e pode ser o jeito mais fácil.
A parte mais difícil é manter o aplicativo morto. Afinal, você precisa armazená-lo em algum lugar internamente, o que significa que, se for óbvio demais, pode ser facilmente subvertido e, mesmo que não seja óbvio demais, pode ser revertido facilmente restaurando a (s) tabela (s) apropriada (s) / arquivos). Portanto, sugiro um segundo método de proteção também.
Esse método armazenaria "LIVE" ou "MORTO" (ou algo suficientemente semelhante) em uma tabela ou arquivo, mas novamente HASHed. Isso precisa ser feito com seu sal E com um carimbo de data e hora. Sempre que uma página em seu aplicativo for executada, verifique esse valor com uma versão em hash de "LIVE" + salt + timestamp e permita um intervalo válido de timestamps (por exemplo, um dia, dois dias, uma semana, um mês etc.) Lembre-se de que quanto maior o alcance, mais difícil será o desempenho.). Desde que as coisas correspondam (ou uma correspondência seja encontrada), o aplicativo estará ativo; caso contrário, mesmo que o valor no arquivo ou tabela especial seja "LIVE", ele ainda estará inativo se houver uma tentativa de restauração do backup, pois o registro de data e hora ficará fora do seu limite.
Em resumo (isso pressupõe que você tenha algum método programático de verificar a validade de uma chave de licença, como algum tipo de soma de verificação ou outro método):
Agora, Deus sabe que há um milhão e uma das maneiras pelas quais isso pode falhar. Considere todas as formas possíveis e crie um sistema confiável (incluindo um que pressupõe que o cliente esteja certo se o arquivo da lista negra não puder ser baixado). Teste, teste, teste e, em seguida, teste um pouco mais antes da implantação, porque se der errado, você perderá a confiança do seu cliente.
fonte
license-server.example.com: no route to hostagora? O servidor de licenças não pode mesmo existir em algum momento no futuro - e não me diga que a sua empresa vai ainda estar vivo em vinte anos, ou seja, em vez estatisticamente improvável.As outras respostas já fizeram um bom trabalho ao cobrir o lado técnico. Mas, por favor, considere também o lado legal.
Você tem o direito de bloquear o aplicativo deles se eles não pagarem? Se você não mencionou isso de antemão no contrato, pode não ter o direito de fazê-lo, mesmo se os pagamentos expirarem (como se você não tivesse necessariamente o direito de retomar algo que vendeu). Além disso, muitos países têm leis especiais que proíbem a "manipulação de programas de computador" - o que você faz pode ser considerado como tal e pode até expô-lo à responsabilidade criminal.
Então, eu aconselho a discutir isso com um advogado primeiro, para evitar entrar na água quente.
No final, pode ser melhor confiar apenas no sistema legal. Se eles não pagarem, negociam e, se isso não ajudar, basta processar. Em muitos países, processar é relativamente fácil e barato se a situação do contrato for clara (na Alemanha, por exemplo, você pode obter um Mahnbescheid por menos de 20 €).
fonte
Se eles estão hospedando internamente, como isso é diferente de qualquer outro software que você possa enviá-los? Descubra o que você faria se estivesse enviando, por exemplo, um aplicativo de exibição de inventário de desktop, e faça isso.
fonte
Depende do sistema. Você estendeu uma estrutura existente como o Magneto ou escreveu um aplicativo inteiro do zero? Se for mais tarde, a construção de um requisito de licenciamento não é muito difícil. Você acabou de entregar o aplicativo com uma licença de curto prazo, uma que expira 45 dias após a cobrança e depois concede uma permanente mais tarde.
Isso pressupõe que você não está entregando a fonte também. :)
fonte
Como o sistema é hospedado internamente, muitas das soluções mencionadas acima que envolvem a comunicação com um servidor remoto podem não funcionar.
Por que não incluir um arquivo de licença no projeto que inclua uma data de validade. Quando o relógio do sistema excede o prazo de validade, o sistema deixa de funcionar. Para proteger o arquivo, criptografe o conteúdo para evitar violações. Quando o usuário paga ou renova por um ano extra, você envia um novo arquivo de licença.
Observe que, se você estiver usando PHP, o código estará prontamente disponível para a edição do usuário; portanto, independentemente do tipo de segurança que você colocar, o usuário poderá facilmente removê-lo. Se você estiver usando o ASP.NET ou alguma outra linguagem compilada, isso não é uma preocupação, pois o código não pode ser modificado.
fonte
(Divulgação - trabalho para a Agilis Software, um fornecedor de sistemas gerenciadores de licenças ).
A solução mais eficaz é usar a ativação automatizada do produto com uma concessão de licença. Fora da caixa, isso permite que você:
fonte