Esperienza utente
In termini di esperienza utente, hai giù:
- L'utente richiede l'invito
- Qualcuno o un processo concede l'invito e una e-mail viene inviata all'utente
- L'utente fa clic su un collegamento, viene chiesto di inserire i dettagli di registrazione
Per le iscrizioni ai referral:
- L'utente richiede l'invito per un altro utente
- Agli altri utenti viene automaticamente concesso l'invito e l'e-mail inviata
- L'altro utente fa clic su un collegamento, viene chiesto di inserire i dettagli di registrazione
Attuazione
In termini di implementazione, tuttavia, mi hai perso a "hash reversibile".
In breve, utilizzerei un token a una volta (stringa arbitraria) per la convalida dell'invito e ho una tabella per memorizzare gli inviti.
La tabella sarà simile a:
- InvitationId - identity
- Email - stringa
- Creato - Data / ora
- Token - stringa
- Scadenza - Data / ora
I due processi sono in realtà abbastanza simili, quindi coprirò entrambi i pezzi insieme.
1. Richiesta di invito
L'utente inserisce la propria e-mail, richiedendo un invito o come utente esistente, immette un'e-mail per un altro utente.
In entrambi i casi, ciò renderebbe una nuova voce nella tabella inviti , popolando i campi Email e Crea .
Nel caso di un utente esistente che invia un invito, invocherebbe immediatamente la parte successiva:
2. Concessione di invito
Quando qualcuno o qualche processo decide di concedere l'invito, farebbe due cose:
- Genera una data token e Scadenza casuali e aggiorna la tabella
- Invia una e-mail contenente un URL di registrazione con il token
Ci sono molti modi per generare un token casuale, ma qualcosa di semplice potrebbe essere lo sha1 di un Guid, quindi ti ritroverai con qualcosa come 1bde8e3ed5709cb399cff0e910442d9b99e181fb .
Dovresti quindi inviare il link come https://mysite.com/signup?token=1bde8e3ed5709cb399cff0e910442d9b99e181fb
3. Registrazione
La prima cosa da fare, ovviamente, è convalidare il token ricevuto: esiste e non è ancora scaduto?
Se tutto è buono, allora permetti all'utente di registrarsi e, al termine, rimuovere la voce invito .
Note aggiuntive
L'approccio basato sui token è molto più sicuro, dal momento che non può essere "incrinato". Qualcuno dovrebbe usare la forza bruta per indovinare ogni possibile token, e si potrebbe attenuare questo bloccando l'indirizzo e-mail per il resto della registrazione a quello dell'invito.
Mantenere questo separato da quello che alla fine sarà il processo di iscrizione "non beta" è anche pulito in termini di uscita dalla beta: dovresti essere in grado di rimuovere questa tabella e il codice relativo abbastanza facilmente, al contrario di avere campi extra memorizzato con i normali account utente. Pensa al token più come un permesso per creare una nuova voce utente.
Tendo a non implementare più del necessario e, non conoscendo il tuo caso d'uso, è difficile speculare su alcune altre cose che potresti voler implementare:
-
Potresti voler mantenere gli inviti per qualche motivo (segnalazione?), quindi potresti usare un campo stato o qualcosa di simile, e / o campi data indicanti le varie azioni
-
Potresti voler inviare nuovamente le e-mail, quindi potrebbe essere utile memorizzare i campi che indicano quando sono state inviate e-mail (e quante)
-
Potresti voler tracciare l'origine di registrazione (ad es., diretta da un URL o da un altro utente) e potresti archiviarla in un campo aggiuntivo quando crei la voce invito , e forse anche trasferirlo sul conto una volta che si sono registrati.