Changeset View
Standalone View
src/app/Observers/TransactionObserver.php
- This file was added.
<?php | |||||
namespace App\Observers; | |||||
use App\Transaction; | |||||
class TransactionObserver | |||||
{ | |||||
/** | |||||
* Ensure the transaction ID is a custom ID (uuid). | |||||
* | |||||
* @param \App\Transaction $transaction The transaction object | |||||
* | |||||
* @return void | |||||
*/ | |||||
public function creating(Transaction $transaction): void | |||||
{ | |||||
while (true) { | |||||
$allegedly_unique = \App\Utils::uuidStr(); | |||||
if (!Transaction::find($allegedly_unique)) { | |||||
machniak: This is potentially biggest table in the system. Maybe it would make sense to do normal bigint… | |||||
Done Inline ActionsI intend to expire entries older than 6 months, to an archive table. I'm not sure to which extent this table would grow compared to say, entitlements. In either case, we'll know when it happens. The consideration with any primary key that could potentially be retrieved through an API call is that the target URL must be unpredictable. I.e. if I examined my transaction log, and I got /transactions: [1, 4, 7, 10, 13], I disclose the following details;
Furthermore, it would not be unlikely that the URL to get to the individual entitlements billed in a debit transaction would have some /transactions/<id> URL. Overall, maintaining the unpredictability of the primary key is an additional layer of security (through obscurity), making the application rely on solely access control just that little bit less. vanmeeuwen: I intend to expire entries older than 6 months, to an archive table.
I'm not sure to which… | |||||
$transaction->{$transaction->getKeyName()} = $allegedly_unique; | |||||
break; | |||||
} | |||||
} | |||||
} | |||||
} |
This is potentially biggest table in the system. Maybe it would make sense to do normal bigint autoincrement identifier.