Understand secure public token generation

This guide explains how the module creates the 64-character public token used by email and QR links. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

What you’ll accomplish

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.

Follow these steps

1. Create a delivery note through a supported flow.
2. Go to its admin detail page and use the generated secure link.
3. Check that the token is not displayed in list views or exposed as a predictable sequence.
4. Treat the URL as access-sensitive evidence.

Fields and options to review

• 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

Rules the system enforces

• 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.

How to confirm it worked

• Recipients receive an unguessable public URL tied to one delivery note.

Safety checks and troubleshooting

• Because the link acts as a bearer secret, share it only with the intended recipient.

Continue with related guidance