---
title: Unlock flow
description: What a visitor sees for a password- or allow-list-gated file, and how the unlock is remembered.
---

# 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](/concepts/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](/sherserve/tools).