Block known addresses or ranges, manage attempt-limit exceptions and restrict selected roles by network.
Available in the current release. The expanded IP access rules screen arrived in 3.0.
This example follows a role restricted to selected networks.
A colleague on the selected network can continue to verification.
Network access is not proof of identity.
A user reaches the login flow from a visitor address identified by the site.
FluentAuth uses the visitor IP, with trusted proxies configured where required.
The configured network restriction determines whether this role may continue from that address.
An allowed network does not replace the user’s required second factor.
An internal editorial team may have different access needs from a public community. Known unwanted addresses and carefully defined team networks deserve distinct rules.
Block rules restrict specified addresses or ranges. Separate role restrictions limit where selected roles can sign in. Allow rules only skip attempt limits, so they do not remove the need for two-factor authentication.
Fit access rules to how your team works, without treating an address as proof of identity.
Get FluentAuth →Available in the current release. The expanded IP access rules screen arrived in 3.0.
Follow the setup guide →
An allow rule is an attempt-limit exception. It does not automatically create a trusted network, grant role access or bypass two-factor authentication.
Before restricting an administrator role, account for remote staff and changing network addresses. Test the intended allowed connection and keep a recovery route available in case the address changes.
Configure trusted proxies before relying on forwarded visitor IP addresses. A rule is only as useful as the address the site can reliably identify.
Plan your team’s network policy and recovery route before applying role restrictions.