shadcn.io is not affiliated with official shadcn/ui
IP Allowlist Settings Block for React
An IP allowlist settings panel with an enforcement switch and a lockout guard that says whether your own address is covered, a rules table, and an add form that parses IPv4 and IPv6 ranges and names the rule that already covers a new one.
Installation
Overview
Keep a service reachable only from the places you trust without locking yourself out, with this IP allowlist settings panel for React with Base UI. A hairline frame with a plus mark on each corner leads with an enforcement Switch and a sentence that says whether your own address is covered by an active rule: covered, and by which one, or not covered, so turning it on would lock you out. Turning it on while you aren't covered is refused with a message and focus on an Add my address Button that adds you as a single address. Below it a native table lists the rules, each an address or a CIDR range in monospace with how many addresses it holds, a label and when it expires, with a Remove button; a rule that has expired stays on the list and counts for nothing. An add form takes a range, a label and an expiry from a Native Select (Never, 30 days, 90 days, with the date they end), understands IPv4 and IPv6, refuses everything (a /0), a duplicate and a range an active rule already covers, and says which rule covers it. The action foot counts unsaved changes beside a Shine Button that saves them and an outline button that discards them. It's built from Switch, Native Select, Field, Input, Button, Shine Button and Guides, with a CSS entrance only. For a gateway, an admin console or any product with an office or VPN allowlist.
FAQ
How do I fill it with my own rules and my own address?
Edit SAVED at the top: each rule has an id, a CIDR or a single address, a label and the day it expires (empty for never). VISITOR is the address the check uses, which in your app comes from the request, and AS_OF is the fixed day expiries are measured from. The sizes, the expiry words, the counts and the guard sentence are worked out from those, so nothing is typed twice. The ranges here are the documentation blocks reserved for examples.
How are the ranges parsed and compared?
An IPv4 address or an IPv6 address, with an optional prefix length, is turned into its bits; a single address is a /32 or a /128. One range covers another when it has the same IP version, a prefix that is no longer, and the same leading bits, which is how the overlap check, the covered check and the guard all work, with no library. Expired rules are ignored by the covered check, and an address with a part over 255, an IPv6 group that isn't hexadecimal or a prefix that is too long is refused with a message.
What exactly does the lockout guard stop?
Two things. Turning enforcement on while your address isn't covered by an active rule is refused, the switch stays off and focus goes to Add my address. If enforcement is on and you remove the rule that covered you, the sentence turns into a warning and Save refuses with a message and the same focus, because saving would lock you out. Pressing Add my address when you are already covered says so and changes nothing.
What stays local, and how do I make it real?
Everything. Nothing is blocked, saved or sent: the rules and the switch live in this page's state, and Save only says what it kept. To make it real, send the saved list to your API, enforce it where requests arrive, and run the same covered check on the server before accepting a change so another client can't lock the account out either. Resolving the address a person is really coming from, behind proxies, is your server's job.
How does it look on a phone, and is it accessible?
Below the medium breakpoint the table becomes one card per rule with the range, the label, its size and expiry and a Remove button, the add form stacks, and the action foot is pinned to the bottom of the screen. The table is native, with a caption, column headers and the range as each row's header, every Remove button is named for its range, and when you remove a rule focus moves to the rule that took its place, or to the add field if none remains. The status line is a polite live region present from the start.
Related
- Pro
A network check for a sign-in: type an IPv4 address and real CIDR maths says which of three allowed ranges holds it, then either continues or asks for access with a reason.
- Pro
Security Checkup Settings
Sign-in and securityA workspace security checkup page with a score and meter, eight checks that each say Pass or Needs attention with a reason and a button that flips them, and one primary button that moves focus to the first failing check.
- Pro
Session Policy Settings
Sign-in and securityA session policy settings panel that leads with the sentence the settings amount to, two sliders with stops for the idle timeout and the longest session that hold each other to one rule, a device limit and an end-all-sessions dialog.
- Pro
CORS Allowed Origins Settings
API and webhooksA CORS settings panel that checks its own origin list for four unsafe patterns, each with a Fix button that rewrites the list, plus origin rows with an environment tag, a validating add form and a policy band for credentials and preflight cache.
- Pro
IP Allowlist Account
Sessions and devicesAn allowlist built from the networks of the last 12 sign-ins and rehearsed against them: seen networks with Allow, the allowed set, one field to add a range, how many sign-ins would pass or be blocked, and a switch refused while your own address is outside the list.
- Pro
Access Token Hygiene Settings
Sign-in and securityAn access token settings panel that flags risky tokens (no end date, unused for 90 days, the admin scope, ending soon), gives a token an end date from a menu, and revokes the ticked ones after an alert dialog lists them.