Passcode-protecting Nuxeo external shares: design and limits

What an email passcode can establish

Nuxeo Instant Share grants an external recipient access through an emailed link, with permissions and an optional validity period selected by the sender. Nuxeo permission documentation

A custom passcode step can require access to the intended mailbox before allowing a protected share to proceed. It does not establish a person's identity beyond that mailbox, prevent the recipient from sharing the code, or replace the repository's document permissions.

Define the authentication boundary

The earlier example used Nuxeo's LTS 2023 TokenAuthenticator as an extension point. Treat it as a version-specific starting point, not a complete authentication implementation.

Do not exempt a request because its User-Agent claims to be Nuxeo Drive. That header is supplied by the client. If a trusted integration needs different behavior, give it a separately authenticated policy that a public share request cannot select.

Design the challenge lifecycle

Associate a challenge with the server-validated share and intended recipient. Generate the code using a cryptographically secure generator; use a short expiry and a bounded number of verification attempts. Limit code delivery so repeated requests cannot flood the recipient's mailbox. Consume a successful challenge atomically so concurrent requests cannot reuse it.

These design choices apply established one-time-code principles from OWASP's token and code guidance. That guidance concerns account recovery; it is a reference for the challenge controls, not a Nuxeo implementation guide.

Submit the code over HTTPS in the request body. Keep codes out of URLs and application logs. Re-check share validity and permissions before granting access, and define the lifetime and scope of any resulting session.

Use storage as one component, not the policy

A Nuxeo key-value store can hold challenge state. Define how the store represents expiry, attempt counts and successful consumption. A string comparison alone does not implement the complete lifecycle. Fail closed when the policy or challenge state cannot be checked.

Acceptance cases before release

Test	Expected result
Forwarded link, no code	Protected content remains inaccessible.
Incorrect, expired or previously consumed code	Verification is denied.
Two simultaneous uses of one valid code	Only one challenge consumption succeeds.
Changed User-Agent	The same verification policy applies.
Repeated send requests	Delivery limits prevent uncontrolled email volume.
Revoked or expired share	A previously issued challenge cannot restore access.

This is a design review and test plan, not a tested drop-in add-on. Confirm the installed Nuxeo release, authentication chain and session behavior before implementation. Discuss the requirements with Maretha's integration team.