Potresti sicuramente farlo, ma non è una configurazione ideale perché stai bloccando l'account e della tua licenza utente su una singola macchina che può e cambiare. Puoi offrire ai tuoi utenti un'esperienza utente migliore (UX) semplicemente creando loro normali account email / password, con cui la loro licenza e la loro macchina sarebbero associate.
Si finirebbe con pochi modelli utente (mantenendolo semplice),
class User
has_one :license
has_one :machine, :through => :license
end
class License
belongs_to :user
has_one :machine
end
class Machine
belongs_to :license
has_one :user, :through => :license
end
che ti consente di tenere traccia dei tuoi utenti, delle loro licenze e anche delle macchine che possono utilizzare. Puoi aggiungere un attributo al tuo modello di macchina in modo che tu possa memorizzare la sua "impronta digitale", ad es. un indirizzo MAC può funzionare bene qui. Ho omesso altri attributi del modello (come la "chiave" di una licenza) al fine di mantenerlo semplice.
Ora ogni volta che l'utente acquista il prodotto, è possibile creare una nuova licenza per il proprio account utente senza macchine associate. Quindi, quando si avvia il prodotto per la prima volta, è possibile prendere l'indirizzo MAC del proprio computer e associarlo alla licenza dell'utente (in background o in modo interattivo). Bam! Ora puoi verificare periodicamente se la macchina corrente è autorizzata inviando una richiesta autenticata di base contenente l'indirizzo MAC della macchina al tuo server di licenze, rispondendo con il risultato della convalida.
Tornando indietro a ciò che ho menzionato in precedenza per fornire agli utenti una UX superiore: ora hai un modo per accedere tramite una normale combinazione di email / password ( che è quello a cui sono abituati ). Da lì, è possibile controllare il proprio account utente per vedere se la macchina corrente esiste e ha una licenza. Alla fine, questo è così molto meglio per l'utente on-boarding che richiedere che tengano traccia di e inseriscano lunghe chiavi di licenza criptiche.
(E se vuoi essere ancora più user-friendly, puoi consentire loro di aggiungere nuove macchine e acquistare licenze aggiuntive direttamente dal tuo prodotto, perché diciamocelo: avranno una nuova macchina alla fine e dovresti rendere il più semplice possibile per loro continuare a utilizzare il tuo prodotto e darti dei soldi. Qualcosa come una finestra di dialogo che dice "abbiamo notato che stai usando una nuova macchina, vorresti acquistare una licenza? per questo e / o disattivare una macchina più vecchia? ")
Ovviamente questo sta iniziando a diventare piuttosto complicato, e non abbiamo nemmeno scalfito la superficie di cose come consentire licenze e licenze multiple per utente, licenze fluttuanti (una licenza per molte macchine - si pensi: una licenza di squadra), licenze per funzioni specifiche nel prodotto o licenze che scadono dopo un certo periodo di tempo (ad esempio, forse una prova limitata).
Ovviamente, non è necessario per implementare tutto ciò e puoi mantenerlo semplice quanto necessario. Volevo solo soffermarmi su alcuni problemi che ho riscontrato così come alcuni pensieri su UX. Ho creato alcune API per le licenze e alcune sono ovviamente più complicate di altre a seconda del prodotto e del tipo di base di utenti che stai vendendo.
Ora, con tutto ciò detto, la maggior parte delle volte gli sviluppatori vogliono solo creare il loro prodotto e non devono preoccuparsi di anche costruire un sistema di licenze per il loro prodotto ( che può richiedere giorni o addirittura settimane e alla fine ritarda il tuo lancio, che fa schifo).
Quindi, se non vuoi per costruire la tua soluzione, ho creato Keygen esattamente per questo scopo. Keygen è una licenza JSON per licenze di prodotto flessibile creata per gli sviluppatori . Speriamo che offra agli sviluppatori un modo per spedire i loro prodotti prima e non perdere tempo a costruire server di licenze.