Sign-in and access Last updated: 23. Oct 2026

The order a request meets them: the firewall and the security level come first. On a publication without sign-in the router runs next, before the page cache. On a publication with sign-in, Docly's sign-in and access check come first, and the router runs after them, for signed-in users only — it can narrow access, never widen it.

On a publication without sign-in, everything the folder serves is public: pages, uploaded files by their path, scaled images, and .docly documents rendered through a display template for their schema (#/<Schema>.hash or .html, or a schema template that allows publishing). A document whose schema has no display template answers 404.

See Keep private data under the # folder, The Root folder, The Folder folder, The API folder and Probes for .git and other flagged URLs count against your IP.

Turn on Require login in the publish dialog (authMode 2; 3 is accepted and works the same). Every request to the publication then needs a Docly session. A page view is sent to the Docly sign-in page and back; a background call that does not accept text/html, such as fetch, gets 401 with {"ResultCode":401,"Message":"Login required.","LoginRequired":true}.

After sign-in, the visitor needs Visit access — through a share — to the file or folder they open. A user without access is sent back to the sign-in page with a message that their user has no access to the page. In API scripts, request.user holds the signed-in user's e-mail address. Pages are cached and shared by all signed-in users, so never render per-user data in a .hash page — see Hash files are cached.

Details on publishing with sign-in: Publishing a site.

The sign-in page is Docly's: the visitor signs in with their Docly account, and the page shows the publication's verified address under to continue to. If the workspace's subscription includes Customizable sign-in, a published folder can add its name and logo in a small card there — never colours, backgrounds or free text.

Set it with Customizable sign-in page under Require login in the publish dialog. Docly stores it in the site's own #/login.json; turning the switch off writes "enabled": false and keeps the name and logo. The name is cut at 60 characters, and the logo is a path in the site to a PNG, JPG or WebP image of at most 256 KB, looked up in the site and then in the app. Without the feature on the subscription, the file has no effect.

See Site.json config file for the login section and how it is inherited from the app.

With sign-in on, the shares decide who gets in. In the share dialog, Web access gives Visit only: the user sees the published pages, but not the content in Docly. Read only, Read and write and Admin include Visit, and Block shuts a user out even when access is given in a folder above or to everyone. A share applies to the folder and everything below it, so a share on a subfolder opens that part of the site. Someone without a Docly account gets an invitation to create one.

From an API script, addFolderShare creates a share and sends the invitation — docly.addFolderShare("/", email, "V", message) gives web access to the whole site. removeFolderShare, getFolderShares and addFileShare do the rest. They run as the site's publisher, so the endpoint that calls them must check who is asking.

For your own identity provider, or for machine calls with a token, publish without sign-in and let the site router protect the site: one script in #/Services/ that runs before every request — pages, files, images and API calls — and lets it through, sends it to sign-in or refuses it. Start from deny: name what is public, and require the session for the rest.

When the sign-in completes, the router writes the session with writeJwt; later requests read it as request.Jwt, in the router and in API scripts. deleteJwt ends it, and return docly.denyAccess() in an API script answers 401 (denyAccess). The token is signed with a secret per site, not encrypted, and only valid on the day it was issued. Pages never see request.Jwt. A router that fails answers 500, never the page.

The full sign-in flow and token checks: The site router and Use the site router for your own sign-in and API tokens. On a publication with Docly sign-in, docly.logOut() ends the Docly session instead (logOut).

API scripts read and write with the site's rights, not the visitor's: docly.saveFile, patchFile and deleteFile write wherever they are told. The check is your code. Decide who is calling from request.user (Docly sign-in) or request.Jwt (your own sign-in), ask what the visitor's shares allow with allowVisit, allowRead and allowModify, and check the document you actually write.

See Check access on the document you write, State-changing API endpoints must require POST and Path traversal.

The security section of #/site.json (or #/security.json, inherited from the app) decides which visitors must pass a Cloudflare Turnstile check before the site answers anything: normal (nobody), elevated (probes, flagged addresses and low-trust countries), high (everyone except high-trust countries) and underAttack (everyone). The check runs before the page cache and before the router, so cached pages are covered too.

From high up, search engines and machine clients are stopped as well: set until so the level ends by itself, and put webhooks and other machine calls in exclude. Single published documents are not covered. See Site.json config file and Set a site's security level in site.json.