Sto cercando di impedire che qualcosa di simile accada:
Fondamentalmente lo scambio finanziario utilizzava transazioni non ACID e più richieste inviate molto vicine tra loro potevano portare a ritiri duplicati o qualcosa del genere.
Una domanda preliminare che ho è, come viene definita questa vulnerabilità? Un attacco di temporizzazione di qualche tipo?
Ecco la mia configurazione:
Sto impostando due tabelle, una per una coda di pagamenti (vale a dire il pagamento in sospeso da prelevare), l'altra per una cronologia dei pagamenti (ossia una ricevuta dopo che l'articolo della coda di pagamento è stato ritirato).
Il mio flusso di elaborazione consiste nel trovare la coda dei pagamenti per id, fare un mucchio di cose asincrone, elaborare un pagamento, quindi creare un oggetto della cronologia dei pagamenti ed eliminare l'oggetto della coda dei pagamenti.
Quali sono alcune strategie riguardo al flusso di processo che potrei implementare per assicurarmi che se un utente tentasse di accedere a questo flusso due volte di seguito molto rapidamente, non ci sarebbero duplicati o problemi simili?
Ho considerato che prima di iniziare il processo potevo cancellare l'oggetto della coda dei pagamenti, quindi con transazioni ACID che avrebbero garantito che il processo non potesse essere duplicato in un attacco di temporizzazione, corretto? È questo il modo migliore per farlo?