Security, sessions and IP access rules

The Security page shows who is signed in and from where, keeps a history of every sign-in attempt, and lets you limit where people can sign in from. It also holds the session rules: idle sign-out and the number of browsers per user.

Go to Administration › Security. Security settings apply to the whole site, so you need to be a site administrator (see Organisations).

The page has four tabs:

Signed in now

This tab lists every browser that was signed in within the last day, 50 to a page (type a user name to find theirs). For each session you see:

• the User and the sign-in method (Password or Windows);
• From: the IP address;
• Browser: for example "Edge on Windows" (hover to see the full browser string);
• Signed in and Last active times.

Your own session is marked this browser.

End a session

1. Find the session in the list.
2. Click End session and confirm.

That browser is signed out on its next click. You cannot end your own current session here; use Sign out in the account menu instead.

Sign a user out everywhere

Click Sign out everywhere on any of the user's rows and confirm. Every session of that user ends, on every PC.

Tip: Use Sign out everywhere when a laptop is lost, or when someone leaves. Then untick Active on the user under Users & roles, so they cannot sign in again.

Sign-in history

Every sign-in attempt is recorded: password and Windows, successful and failed.

1. Open the Sign-in history tab.
2. Set the filter:
   • User: part of a user name;
   • Result: All, Signed in or Failed;
   • Days: 1, 7, 30 or 90.
3. Click Show.

Failed attempts show the reason:

Sign-in history is kept as long as the audit log. The Audit log retention (days) setting controls both. It shows 50 sign-ins to a page with page numbers below; choose 25, 50, 100 or 200 a page. Like other long lists, it has a row filter and downloads as Excel or CSV.

Tip: Many "Unknown user" or "Wrong password" failures from one address in a short time can mean someone is guessing passwords. Add a Deny rule for that address on the IP access tab.

IP access rules

IP access rules decide which addresses users can sign in from. This is how you build an IP allow list, for example "only from the office network", or block a single address.

How rules are applied

• Deny rules always win. If a deny rule matches the user and the address, the sign-in is refused.
• Allow rules restrict. When at least one allow rule applies to a user (because it is for everyone, for one of their roles, or for them), that user can only sign in from the allowed addresses.
• No rules means users can sign in from anywhere.
• The server itself (localhost) is always allowed. An administrator can always get back in by signing in on the web server.

Rules are checked before the password, so a blocked address learns nothing about the account. They apply to new sign-ins at once, and to users who are already signed in within 30 seconds.

Add a rule

1. Open the IP access tab.
2. Under Add a rule, choose:
   • Rule: Allow or Deny;
   • Address or network: a single address such as 10.1.2.3, or a network in CIDR form such as 10.1.0.0/16. IPv6 works too, for example 2001:db8::/32;
   • For: Everyone, A role (then pick the role) or A user (then type the user name).
3. Optionally, type a description, for example "Head office network".
4. Click Add rule.

To remove a rule, click Remove on its row and confirm.

The page shows Your address above the list. Check it before you add an allow rule, so you do not lock yourself out.

Try an address

Before you rely on a set of rules, test them:

1. In Try an address, type an IP address. Your own address is filled in for you.
2. Optionally, type a user name or choose a role.
3. Click Try.

The result says whether that address is allowed, or which rule denies it.

Example: office-only access for operators

Operators can now sign in only from these two networks. Other roles are not affected, because no allow rule applies to them.

Important: If DocView Capture runs behind a load balancer, reverse proxy or Azure App Service, set "ReverseProxy": { "Enabled": true }. Otherwise every request seems to come from the proxy, and rules and sign-in history show the proxy's address. See the configuration reference.

Only accept requests from your own networks

IP access rules decide who can sign in from where. To close the whole site to everyone outside your networks, for example a site in the cloud that only your offices and your DocView Workers use, list the networks in System settings › Security › Only accept requests from: addresses or ranges, comma separated, for example 203.0.113.0/24, 198.51.100.7.

When the list is set, every page, the REST API, scan uploads and DocView Workers answer only those addresses (and the server itself). Anyone else gets Access … is not allowed. Health checks still answer, so the hosting platform can see the site is running.

• Include your own address first. The setting takes effect within half a minute.
• The list can also be set where the site is hosted, as the server setting Security:AllowedNetworks (for example an App Service application setting); both lists count.
• Locked out? Set the server setting Security:IgnoreAllowedNetworkSetting to true and restart: the list in System settings is ignored until you correct it.
• Behind a proxy such as Azure Front Door or Application Gateway, set ReverseProxy:KnownNetworks to the proxy's address ranges so the real client address is used (see the configuration reference).

Server folders on a site with several organisations

On a site with more than one organisation, organisations other than Default may export to or watch only the folders a site administrator lists in System settings › Security › Server folders for other organisations (separated by semicolons). With none listed, only the Default organisation uses server folders; the others use cloud storage, SFTP or their own connectors. C# scripts, which run on the shared DocView Worker, are also kept for the Default organisation and site administrators on such sites.

Session settings

1. Open the Session settings tab.
2. Set:
   • Sign out after idle time (minutes): a browser not used for this long is signed out. Use 0 to keep sessions until the sign-in expires (10 hours). The maximum is 1440 (24 hours).
   • Sessions per user: how many browsers one user can be signed in on at once. Signing in again ends the oldest session. Use 0 for any number. The maximum is 50.
3. Click Save.

The same two values also appear on the Settings page.

Tip: A value of 1 for Sessions per user stops people sharing an account on several PCs. A value of 2 still allows one PC and one laptop.

Built-in protections

These protections are always on:

• accounts lock for 10 minutes after 5 wrong passwords;
• passwords need at least 10 characters;
• the sign-in page is rate limited per client address (30 attempts a minute by default, see RateLimits:LoginPerMinute in the configuration reference);
• every sign-in is recorded in the sign-in history;
• the default password of a new installation (DocView@2026!) must be changed before anything else can be done;
• only a site administrator can change a site administrator's account (password, name, roles), so an organisation's administrator cannot take it over;
• a forwarded address can never pretend to be the server itself, and going back to the previous page only ever goes to a page of this site;
• secrets such as passwords and API keys are stored encrypted (see Settings).

Audit trail

Changes on this page are written to the audit log, for example IpRuleSaved, IpRuleDeleted, SessionEnded, SessionsEnded and SettingChanged.

Related pages

• Users, roles and permissions
• Windows sign-in
• Audit log
• Settings