Understand secure public token generation
Understand how the module creates the 64-character public token used by email and QR links.
Exact navigationNo staff action → Token is generated automatically when a delivery note is created
What this guide covers
Understand how the module creates the 64-character public token used by email and QR links. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Exact step-by-step process
- Create a delivery note through a supported flow.
- Open its admin detail page and use the generated secure link.
- Verify that the token is not displayed in list views or exposed as a predictable sequence.
- Treat the URL as access-sensitive evidence.
Fields, choices and supported possibilities
- Primary source: `random_bytes(32)` encoded as 64 hexadecimal characters
- Fallback: OpenSSL secure pseudo-random bytes
- Final compatibility fallback: SHA-256 over unique/random inputs
Code-backed validations and workflow rules
- The database enforces token uniqueness.
- The supplied code does not implement token expiry, rotation or revocation.
- Voiding the note blocks public access even though the token remains stored.
- Signing changes the record to sealed read-only behaviour but retains the link for viewing.
- The final `uniqid`/`mt_rand` compatibility fallback is weaker than `random_bytes`; supported production PHP 7.4+ should use the primary `random_bytes` branch.
Expected result and verification
- Recipients receive an unguessable public URL tied to one delivery note.
Checks, security and troubleshooting
- Because the link acts as a bearer secret, share it only with the intended recipient.
Stay within the supported flowDo not force database values, expose secure tokens, bypass permission checks, replace a stored signature or invent a status or interface that the supplied code does not implement.