shadcn.io is not affiliated with official shadcn/ui
VPN Required Login Block for React
A sign-in gate for a VPN-only console: a connection check that fails twice with different diagnoses and then passes, three numbered steps, a demo switch to pretend, and troubleshooting answers.
Installation
Overview
Tell people to connect first and let them check from the same page, with this VPN required login block for React with Base UI. It's the gate in front of Haulgate, a logistics admin console: a whole screen with the page's rails and one band across it, a centred column. A state band names where the connection stands, Not connected, Checking or Connected, as a word with a glyph and a Status dot, and one sentence that says why. The one Shine Button, Check connection, runs a scripted check of 800 milliseconds that fails with one diagnosis, fails with another and then passes, after which it reads Continue to Haulgate. A Switch marked as a demo control pretends the connection, and Start over puts the script back at its first attempt. Below sit three numbered steps (open an IKEv2 or WireGuard-compatible client, connect to the company profile, check here) and an Accordion of troubleshooting answers whose panels share one height, so opening one never moves the page. It's built from Status, Accordion, Switch, Button, Shine Button and Guides, with a CSS entrance only. For consoles, admin tools and anything that answers only on a company network.
FAQ
What stays in the page, and how do I wire it for real?
Everything, and nothing here detects a VPN. The three checks are a typed script (two failures with different diagnoses, then a pass) and the switch simply pretends. In a product the check is a request to a health endpoint that only answers on the VPN side of your network, or your gateway reports whether the session arrived through the tunnel; use the diagnosis it returns in place of the typed ones, and enforce the rule on your server, never in the page.
Why does the check fail twice before it passes?
To show two different, useful diagnoses: traffic leaving from a public network address, and a tunnel that is up with no route to the console. Each is a line in ATTEMPTS, so you can reorder them, add more or make the first one pass. Start over runs the script again from the first check.
Which VPN clients does it name?
None. It says "an IKEv2 or WireGuard-compatible client", because the page cannot know which one your company uses. Replace the three steps with your own, and name your client in them if you want to.
How does the troubleshooting list behave?
One answer is open at a time and it stays open, so every panel has the same height and the page never shifts. Tab moves between the question rows; arrow keys do not.
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
A sign-in that works only in set hours: a week grid of 24 hour cells for each day with a derived next window, a readout for any cell, and a request for off-hours access.
- Pro
A sign-in that runs four policy checks in order (device, network, identity, policy) on a vertical Steps rail with typed details, a demo control that makes the device fail, and an outcome with its fix.
- Pro
A sign-in that follows the browser's real online and offline events: offline it asks for an eight-character offline code and counts sessions, online it says no code is needed, in the same space.
- Pro
IP Address Blocked Error
Blocked and limitedA full-screen blocked-address page for a bot-protection layer: a review request form (organisation and reason) beside the evidence: the address with Copy, a five-part bar for 5 of 5 failed sign-ins in 10 minutes, the five attempts and when the block lifts.
- Pro
Account Locked Login
Recovery and resetA locked-account page for a point-of-sale system that draws the lockout ladder, marks the rung the account is on with a fixed unlock time, and offers an unlock link by email or a password reset.