Come faccio a inviare nuovamente un token di conferma, se due persone diverse cercano di registrare lo stesso indirizzo email?

Question

Come faccio a inviare nuovamente un token di conferma, se due persone diverse cercano di registrare lo stesso indirizzo email?

#1 da (2 voti)
#2 da (1 voti)

0

Sto progettando un'API REST che consente agli utenti di registrarsi e autenticarsi con un indirizzo email e una password. Prima di essere in grado di autenticarsi, voglio assicurarmi che l'utente sia l'indirizzo email che sta utilizzando, quindi invio loro un'email di verifica con un token. Il mio problema è che il token può scadere, quindi ho bisogno di un modo per inviare nuovamente l'email di verifica, ed è qui che sto avendo problemi.

Impostazioni di base

Ho due modelli: EmailAddress e EmailConfirmation . EmailAddress memorizza l'indirizzo, l'utente che lo possiede e un booleano che indica se è verificato. EmailConfirmation contiene una chiave utilizzata per verificare uno specifico indirizzo email.

Approccio 1

Quando un utente si registra, creo un nuovo utente e un'istanza EmailAddress di proprietà dell'utente. Una conferma viene inviata all'e-mail. Se la conferma è scaduta, l'utente può richiedere una nuova conferma.

Il problema con questo approccio è che più utenti possono registrarsi con lo stesso indirizzo email finché qualcuno non verifica tale indirizzo. Se ci sono più istanze di EmailAddress con lo stesso indirizzo, come faccio a determinare quale di esse ha richiesto la verifica per essere rinviato?

Approccio 2

Quando un utente si registra, creiamo un'istanza EmailAddress per l'indirizzo, ma non assegniamo un utente ad esso. Se altri utenti si registrano con lo stesso indirizzo, non creiamo nuove istanze. Al contrario, il modello EmailConfirmation ha un utente collegato e impostiamo la proprietà dell'indirizzo in base alla chiave utilizzata per verificarlo.

Il problema con questo approccio è come determinare quale utente ha richiesto una nuova e-mail di conferma.

Ulteriori note

Gli utenti non dovrebbero essere in grado di impedire ad altri di prendere un indirizzo email. Ad esempio: se Fred registra con [email protected] ma non può verificarlo, Bob dovrebbe comunque essere in grado di registrarsi con [email protected] e verificarlo.

Sono felice di adottare un approccio diverso da quelli descritti sopra, ma quelli sono gli unici a cui riesco a pensare. Qualsiasi aiuto sarebbe molto apprezzato.

Modifica: credo che il titolo originale della mia domanda fosse un po 'fuorviante. Sono più interessato a risolvere i problemi con il reinvio di un'email di conferma. Tuttavia, se ciò comporta la ristrutturazione del mio approccio all'intero sistema, sono felice di farlo.

Modifica 2: Per chiarire ulteriormente la mia domanda, sto parlando del caso in cui un utente si registra e riceve un'e-mail di verifica. Per qualsiasi ragione, non usano il token che hanno ricevuto in tempo e scade, o semplicemente perdono l'email. Richiedono quindi di inviare una nuova e-mail di conferma inviando il proprio indirizzo email.

Credo che il problema si risolva nel determinare quale utente ha richiesto una nuova conferma via email senza alcuna conoscenza del token di verifica iniziale.

authentication

posta Chathan Driehuys 21.09.2017 - 23:08

fonte

2 risposte

1

Capisco che la domanda riguardi esclusivamente la modellazione dell'API REST e non su come generare effettivamente il token, giusto?

Ogni volta che generi una mail di conferma, generi un record di conferma che identifica un utente, un indirizzo email, una data di scadenza e un token unguailable non esclusivo. Quando viene verificata una conferma facendo clic sull'URL del token, l'indirizzo e-mail viene verificato per questo utente (e devi controllare che nessun altro utente abbia verificato lo stesso indirizzo e-mail nel frattempo!).

Non è chiaro dalla tua descrizione se lo stesso utente può modificare l'indirizzo email. Se l'indirizzo email non può essere modificato, allora è una proprietà dell'utente, non la conferma, poiché tutte le conferme per lo stesso uso sarebbero per lo stesso indirizzo.

Per quanto riguarda la modellazione di questo in REST, penso che rispondi tu stesso. La conferma deve essere associata a un utente. Quindi hai qualcosa come /users/1234/confirmation/567 che rappresenta una mail di conferma e lo verifichi pubblicando il token.

Tuttavia, tieni presente che non devi esporre questo URL risorsa direttamente nella mail di conferma. Il token e l'URL devono essere opachi e non riflettere l'URL della risorsa di alcunché, poiché non dovrebbe essere possibile indovinare o eseguire il reverse engineering degli URL di verifica.

risposta data 22.09.2017 - 07:59

fonte

Leggi altre domande sui tag authentication

Come al refactor il seguente codice parallelo per evitare il controllo ridondante? Utilizzo del diagramma dei componenti

score 2 · Accepted Answer

Per entrambi gli approcci, il modo più semplice per risolvere ciò è incorporare le informazioni utente nel token. In questo modo il token contiene informazioni sufficienti per convalidare l'utente e il suo indirizzo email.

Una versione eccessivamente semplicistica potrebbe essere quella di allegare l'id dell'utente al nonce che invii. Ad esempio, se Bob è il numero utente 1234 , l'email potrebbe contenere il token 1234000574628 , dove 574628 è il nonce che utilizzi per confermare che l'utente abbia effettivamente letto l'e-mail.