Security: Users & auth

Where to enable authentication (app UI)

Open the app and scroll to the Security section. Enable Require authorization.

Set credentials

When you enable authorization, the app prompts you to set credentials (username and password). These credentials are required for protected access to the server.

Users & Auth details

After you enable Require authorization and set credentials for the first user, a new button appears under the checkbox: USERS & AUTH DETAILS. This screen lets you manage users and fine-tune how authentication works.

Users tab

The Users tab shows the existing users and provides an Add user button for creating additional accounts.

Settings tab

The Settings tab contains global options, including:

• Authentication mode — choose between session-based authentication and basic authentication.
• Guest access — allow or disallow unauthenticated access.
• Store users in database — persist user accounts in the app’s SQLite database. Required for roles (see Roles below).
• User registration — enable registration, select the default role for new users, and optionally assign a root folder using a pattern.
• Roles management — define named roles and their permissions via the Edit roles button.

Per-user settings

To edit an individual user, open Users & Auth details, go to the Users tab, and tap a user in the list. This opens the User Details screen where you configure credentials and access limits for that specific account.

• Username — the account name used during login.
• New password — set a new password for this user.
• Custom root folder — optionally restrict this user to a specific subtree (a dedicated document root for that user).
• Storage size limit — optionally cap the storage this user can use (and see the current usage).
• Role — assign a role to this user (only meaningful when Store users in database is enabled; see Roles). If a role is set, its permissions take precedence; the per-user access toggles are then controlled by the role and are not editable until the role is cleared or changed.
• Access rights — fine-grained toggles for file access, database access, and system-level operations. Use these when the user has no role, or when you need overrides as described under Roles.

Roles

Roles let you group permissions under a name and assign that bundle to users, instead of configuring every toggle by hand for each account.

Prerequisites

For roles to work, user records must be stored in the app’s database:

1. In the main settings, enable Enable SQLite database (under Database) so the app has a database to use.
2. Open USERS & AUTH DETAILS → Settings and enable Store users in database. Without this, role assignment and role-based behaviour are not available.

Where to configure roles

• Global role definitions — on Users & Auth details → Settings, use Edit roles (under Roles management) to create or edit roles and what each role allows.
• Per-user assignment — on User Details, use the Role dropdown to pick a role for that user. You can also open Edit roles from this screen for quick access to the role editor.
• New users via registration — if Allow user registration is enabled, set the Default role for new users so self-registered accounts get the right role automatically.

Role vs per-user settings

If a user has a role assigned, the permissions defined for that role have higher priority than the per-user access settings on User Details. In that case, the per-user permission controls that would conflict with the role are unavailable for editing until you remove the role or switch to a different configuration. To adjust access for such a user, edit the role itself (via Edit roles) or clear the role and configure the user manually.

What changes for clients (browser / Web UI)

After authorization is enabled, clients connecting to your server may be required to authenticate. This is especially important if you allow write actions (uploads, delete, edit) or expose advanced handlers.

Keep in mind that without TLS, your browser will show the connection as not secure and credentials can be exposed on hostile networks.

Session-based vs Basic auth (high-level)

• Session-based authentication — after logging in, the server sets an HTTP-only session cookie. This mode unlocks the Authentication API endpoints.
• Basic auth — the client sends credentials on each request (usually via the Authorization header). This is simple but should be paired with HTTPS whenever possible.

Exact behavior can vary by app version and configuration, but the core recommendation stays the same: use authentication, limit exposure, and prefer HTTPS on anything beyond a trusted LAN.

Auth API (quick reference)

The following endpoints are documented in the API Documentation section. They are available only when session-based authentication is enabled:

• POST /api/user/login — authenticate and obtain a session cookie
• POST /api/user/logout — clear the session cookie
• GET /api/captcha — captcha used for registration
• POST /api/user/register — register a new user (requires captcha)

Recommended hardening checklist

• Enable authorization before sharing the URL with anyone.
• Prefer HTTPS (TLS) if clients are not on a fully trusted network.
• Restrict exposure — limit interfaces/clients when the option is available (e.g. restrict network interfaces, whitelist client IPs).
• Be careful with write access — enabling file modification makes the web UI much more powerful; protect it.