Understand signature security metadata

Interpret the evidence stored with a successful public signature.

What this guide covers

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.

Exact step-by-step process

1. Open the signed note.
2. Review signed time, IP address and the displayed signature hash.
3. Confirm the stored signature image appears.
4. Review the signed event message and event IP.
5. Compare the sealed public page and generated PDF.

Fields, choices and supported possibilities

• 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

Code-backed validations and workflow rules

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

Expected result and verification

• Reviewers can identify the stored technical evidence without assuming unsupported identity verification.

Checks, security and troubleshooting

• A drawn signature and IP do not by themselves prove legal identity; apply the organisation’s authorised evidential process.

Related Delivery Note guides