Como proteger eficientemente parte de uma aplicação com uma licença

5

Estou trabalhando em um aplicativo que possui muitas partes funcionais.

Quando um cliente compra o aplicativo, ele compra a funcionalidade padrão, mas também pode comprar alguns elementos adicionais do aplicativo por um preço adicional. Todos os elementos fazem parte do mesmo executável do aplicativo. Uma chave de licença é usada para indicar quais elementos devem estar acessíveis no aplicativo.

Alguns dos elementos podem ser facilmente desativados se o usuário não pagar por isso. Estes são normalmente os módulos que você pode acessar através do menu do aplicativo.

No entanto, alguns elementos dão mais problemas:

  • E se uma parte do modelo de dados estiver relacionada a uma parte opcional? Eu construo essas estruturas de dados em meu aplicativo para que o resto do meu aplicativo possa apenas assumir que elas estão sempre lá? Ou eu não os construo e adiciono cheques no restante do aplicativo de maio?
  • E se alguma parte opcional ainda for útil para executar algumas tarefas internas, mas não quero expô-la ao usuário externamente?
  • E se o responsável pelo marketing quiser tornar uma peça padrão agora uma peça opcional? Em todo o meu aplicativo, presumo que essa parte esteja presente, mas se ela se tornar opcional, devo adicionar verificações nela em todos os lugares do aplicativo.

Tenho algumas ideias sobre como resolver alguns dos problemas (por exemplo, interfaces com implementações duplas: uma implementação em funcionamento e uma que é ativada se a parte opcional não estiver ativada).

Você conhece algum padrão que possa ser usado para resolver esse tipo de problema? Ou você tem alguma sugestão sobre como lidar com esse problema de licenciamento?

Obrigado.

    
por Patrick 12.09.2012 / 10:02
fonte

3 respostas

3

Na verdade, estou em uma posição muito semelhante, gerenciando o desenvolvimento de um produto com o mesmo modelo de licença e um banco de dados principal compartilhado por diferentes funções em nosso software.

What if a part of the data model is related to an optional part? Do I build up these data structures in my application so the rest of my application can just assume they're always there? Or do I don't build them, and add checks in the rest of may application?

Eu não conheço o seu produto, mas no nosso nós entregamos sempre o modelo de dados completo. Um modelo de dados em si (ou qualquer parte dele) não é uma função de produto útil para nenhum de nossos clientes - uma função útil é um processo ou operação nesses dados, que é parte do código de aplicativos. Então, nós apenas alternamos a funcionalidade. Considere também que um modelo de dados normalizado tende a fornecer os mesmos dados para funcionalidades diferentes .

What if some optional part is still useful to perform some internal tasks, but I don't want to expose it to the user externally?

Suponho que você esteja falando sobre partes do modelo de dados - realmente importa se você o expõe ao usuário, desde que todos os processos / operações opcionais que o cliente não comprou estejam desativados? E o que "expor" significa? Se você quer dizer "expor" no nível da interface do usuário, deve ser fácil desativar essa interface do usuário. Se você quer dizer no nível do banco de dados (porque você dá aos seus usuários acesso direto ao seu banco de dados), então você provavelmente pode viver com isso.

What if the marketing responsible wants to make a standard part now an optional part? In all of my application I assume that that part is present, but if it becomes optional, I should add checks on it everywhere in the application.

Para minha experiência pessoal, as peças que são feitas opcionais são quase sempre peças que o usuário pode identificar facilmente como funcionalidades separadas. Caso contrário, o marketing teria problemas para anunciar essa função separada. Na maioria dos casos, isso significa que essas verificações não precisam ser adicionadas "em todos os lugares", mas apenas em um pequeno número de locais administráveis.

    
por 12.09.2012 / 20:37
fonte
2

Uma coisa que seria possível, como você mencionou, é ter uma interface com implementação dupla e usar um contêiner DI para injetar condicionalmente o componente adequado, se estiver disponível. Simples e eficaz. Você não precisará realmente adicionar verificações em todos os lugares, pois isso restringe o gerenciamento de módulos a um único local. Isto é, obviamente, assumindo que seu sistema é projetado bem o suficiente para lucrar com um contêiner DI.

    
por 12.09.2012 / 14:26
fonte
2

Parece que você precisa de uma chave de licença ou produto . A pesquisa no Google com "gerador de chaves de licença" exibirá vários resultados, incluindo este , se você quer rolar o seu próprio.

Geralmente, você colocará uma verificação de segurança / licença perto do início do caminho do código licenciado. Seus chamadores precisarão ser capazes de lidar com uma chamada com falha devido a não estarem licenciados.

Idealmente, você terá algumas chamadas que verificam a licença antes de preencher os menus do usuário. É muito mais difícil para o usuário selecionar a "coisa errada" para a qual eles não são licenciados quando a opção não é visível.

Existem algumas maneiras de resolver o problema de áreas em que você precisa usar algumas funcionalidades licenciadas dentro de uma função padrão. Provavelmente, o mais fácil é ter dois caminhos principais para essa função licenciada. Um caminho verifica a licença e, finalmente, fica exposto à interface do usuário. O outro caminho não é exposto e também não verifica o licenciamento.

Da mesma forma com o banco de dados, você pode ter dois caminhos para acessar a funcionalidade. Se algumas das funções padrão realmente dependem de estruturas de banco de dados opcionais, mantenha-as no lugar, mas não exponha o acesso por meio da interface do usuário. Tenha em mente que um DBA ainda poderá acessar essas estruturas de tabela. Geralmente, é a funcionalidade que você fornece em torno das estruturas que são mais valiosas, não as próprias tabelas, portanto, isso não deve ser um problema muito grande.

Para lidar com as mudanças do mercado no que é licenciado ou não, você pode ter todas as funcionalidades principais passando pelas verificações de segurança descritas ou apenas adicioná-las posteriormente conforme necessário. Eu votaria na rota mais preguiçosa e só colocaria a verificação de licença em funções padrão se e quando o Marketing decidir seguir esse caminho.

    
por 12.09.2012 / 15:55
fonte