Come proteggere in modo efficiente parte di un'applicazione con una licenza

In realtà, mi trovo in una posizione molto simile, gestendo lo sviluppo di un prodotto con un modello di licenza analogo e un database principale condiviso da diverse funzioni nel nostro 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?

Non conosco il tuo prodotto, ma nel nostro consegniamo sempre il modello completo dei dati. Un modello di dati di per sé (o parte di esso) non è una funzione di prodotto utile per nessuno dei nostri clienti - una funzione utile è un processo o un'operazione su quei dati, che fa parte del codice delle applicazioni. Quindi abilitiamo la funzionalità solo lì. Considera inoltre che un modello di dati normalizzato tende a fornire gli stessi dati per le funzionalità diverse .

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?

Suppongo che tu stia parlando di parti del modello di dati: è davvero importante se lo esporti all'utente, a patto che tutti i processi / operazioni opzionali che il cliente non ha acquistato siano disattivati? E cosa significa "esporre"? Se intendi "esporre" a livello di interfaccia utente, allora dovrebbe essere facile per te disabilitare quell'interfaccia utente. Se intendi a livello di database (perché offri ai tuoi utenti l'accesso diretto al tuo database), allora puoi probabilmente conviverci.

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.

Per la mia esperienza personale, le parti rese opzionali sono quasi sempre parti che l'utente può facilmente identificare come funzionalità separate. In caso contrario, il marketing si imbatterebbe in problemi per pubblicizzare quella funzione separata. Nella maggior parte dei casi ciò significa che questi controlli non devono essere aggiunti "ovunque", ma solo in un numero maneggevole e gestibile di posti.

Una cosa che sarebbe possibile, come hai detto, è avere un'interfaccia con doppia implementazione e usare un contenitore DI per iniettare condizionatamente il componente appropriato se disponibile. Semplice ed efficace. Non è necessario aggiungere controlli ovunque, in quanto ciò limita la gestione dei moduli in un unico posto. Ciò ovviamente presuppone che il tuo sistema sia progettato abbastanza bene da trarre profitto da un contenitore DI.

Sembra che quello di cui hai bisogno sia una chiave Licenza o prodotto . La ricerca su google con "generatore di chiavi di licenza" mostrerà un numero di risultati, tra cui questo se vuoi rotolare il tuo.

Generalmente, metti un controllo di sicurezza / licenza vicino all'inizio del percorso del codice della licenza. I chiamanti dovranno essere in grado di gestire con garbo una chiamata fallita a causa della mancata concessione della licenza.

Idealmente, avrai alcune chiamate che controllano la licenza prima di compilare i menu utente. È molto più difficile per l'utente selezionare la "cosa sbagliata" per la quale non sono autorizzati quando l'opzione non è nemmeno visibile.

Ci sono un paio di modi per risolvere il problema delle aree in cui è necessario utilizzare alcune funzionalità con licenza all'interno di una funzione standard. Probabilmente il modo più semplice è avere due percorsi principali in quella funzione concessa in licenza. Un percorso controlla la licenza e viene infine esposto all'interfaccia utente. L'altro percorso non è esposto e non controlla nemmeno la licenza.

Analogamente al DB, puoi avere due percorsi per accedere alla funzionalità. Se alcune delle funzioni standard si basano davvero su strutture di DB opzionali, tenerle a posto, ma non esporre l'accesso attraverso l'interfaccia utente. Tieni presente che un DBA sarà ancora in grado di attingere a quelle strutture di tabella. Generalmente, è la funzionalità che fornisci attorno alle strutture che è più preziosa, non le tabelle stesse, quindi non dovrebbe essere un problema troppo grande.

Per affrontare le modifiche del mercato su ciò che è concesso in licenza o meno, puoi avere tutte le principali funzionalità attraverso i controlli di sicurezza descritti o aggiungerli in un secondo momento, se necessario. Voterò per il percorso più pigro e inserirò il controllo della licenza in funzioni standard solo se e quando Marketing deciderà di seguire questa strada.