Understand signature security metadata
Interpret the evidence stored with a successful public signature. 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.
Where to goAdmin Area → Delivery Note → Open signed note
What you’ll accomplish
Interpret the evidence stored with a successful public signature. This guide follows the supplied Delivery Note module’s live hooks, controller actions, model rules, views and stored side effects.
Follow these steps
- Go to the signed note.
- Check signed time, IP address and the displayed signature hash.
- Verify the stored signature image appears.
- Check the signed event message and event IP.
- Compare the sealed public page and generated PDF.
Fields and options to review
- signature_data: data URI
- ip_address from request input helper
- user_agent truncated to 255 characters in note record
- signed_at timestamp
- signature_hash: SHA-256 over token, signature and current time
- Compliance-event IP helper checks CF-Connecting-IP, then the first X-Forwarded-For value, then REMOTE_ADDR
Rules the system enforces
- The hash is evidence metadata generated at signing; the supplied code does not expose an independent verification utility.
- Event storage can retain a longer user agent separately.
- `signed_by_name` and `signed_by_email` are not populated by the current public form.
- `locked_at` is not set in the supplied flow.
- The note’s signing IP uses the CRM input helper; the event timeline separately uses the module IP helper and can therefore reflect trusted proxy headers according to server configuration.
- The active sign method does not set `locked_at`, signed-by name/email or `updated_at`; signed status and the controller/model guards provide the current lock behaviour.
How to confirm it worked
- Reviewers can identify the stored technical evidence without assuming unsupported identity verification.
Safety checks and troubleshooting
- A drawn signature and IP do not by themselves prove legal identity; apply the organisation’s authorised evidential process.
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.
Continue with related guidance
Was this guide useful?Your response is stored only in this browser.
