Possibile modo di gestire più email di reimpostazione della password

Il secondo approccio funziona bene. Ho usato qualcosa di simile in un recente progetto. Quando qualcuno richiede una reimpostazione della password, genera il codice di verifica (utilizzato per il collegamento di verifica) e lo inserisce in una tabella insieme all'indirizzo e al timestamp. Se viene richiesta nuovamente una reimpostazione della password, controlla prima quella tabella e non invierà l'e-mail se è stata fatta un'altra richiesta negli ultimi X minuti.

Esiste un'attività periodica che passa e cancella tutte le voci di reimpostazione della password man mano che scadono (ad esempio, dopo 24 ore).

La tua affermazione sui cookie è corretta. I biscotti sono nelle mani del nemico. Non sono a prova di manomissione, quindi non è possibile utilizzare la mancanza di un cookie come prova che l'utente non ha visitato il sito in precedenza.

Invece di creare una nuova tabella di database, è sufficiente aggiungere un campo last_password_reset_mail_send_timestamp alla tabella degli account utente generale. Quando l'utente (presunto) desidera una reimpostazione della password per un account, verificare se last_password_reset_mail_send_timestamp è inferiore alla data / ora corrente meno l'intervallo di tempo configurato tra le reimpostazioni.

La ragione per salvare l'inizio del periodo di reset-forbidden invece della fine è che con quel design la modifica dell'impostazione temporale influisce anche sulle vecchie voci del database.

Sono d'accordo che i cookie sono una cattiva soluzione. Sarà meglio se tracciamo in una nuova colonna l'ultimo timestamp della richiesta di modifica della password e controlliamo se è sotto x hrs se è l'utente dovrebbe essere mostrata un'altra pagina di verifica dicendo che non ha ricevuto l'email? per favore riattivare qui solo per dare una coperta di smarrimento della posta elettronica o dare un messaggio di riprova post x min.