Unlock flow

A password or allow_list object doesn't refuse a visitor outright — it asks them to prove they're allowed in first.

Password-gated

A visitor without a valid unlock is shown a password form instead of the file. Submitting the correct password sets a signed, httpOnly unlock cookie scoped to that resource's own address, then redirects to the file itself. The cookie is remembered for 12 hours, so the same browser doesn't have to re-enter the password on every visit within that window.

A wrong password re-shows the form with an error, and repeated wrong guesses are rate-limited — 10 attempts per 15 minutes per resource — so guessing a password isn't a viable attack even against a short one.

Allow-list-gated

An unauthenticated visitor is asked to sign in with sherlock first. A signed-in visitor who isn't on the allow-list gets no access — not a "you're signed in but not allowed" message and not a sign-in prompt either, since either would confirm the resource exists to someone who can't see it.

Expiry and view budgets come first

If the resource has expired or used up its view budget, that's checked before the access level itself — a dead allow-listed file never demands a sign-in only to refuse afterward. See access modes for how expiry and view budgets stack on top of every access level.

The same flow, three hosts

This unlock behavior is identical whether the gated resource is a sherpage page (p.), a sherserve object (f.), or reached through a short link (sl.) — sherlink is the single policy owner behind all three.

Next

Tools.