Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Trusted Devices Account Block for React

An account's trusted devices as a table of devices against two switches, one to skip the sign-in code and one to skip the password prompt, with a sentence on what each device's choice means and a meter against the limit.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Let people decide what each device may skip, with this trusted devices panel for React with Base UI. A compact header holds the title and one sentence. Inside a hairline frame with a plus mark on each corner, a heading counts the devices against the limit of five and a segmented meter shows the places filled. A native Table crosses each device (its name, browser and system, and the day it last signed in) with two Switches: skip the sign-in code, and skip being asked for the password again before a sensitive change, which is unavailable while the code is asked. Choosing a device by its name, or a switch on it, writes what that amounts to in the sentence under the table, so the risk is stated rather than implied. Forget is a quiet button that asks in place with Cancel and Confirm and can empty the list, which shows an Empty state. On a phone each device becomes a card with its two labelled switches. It's built from Table markup, Switch, Button, Empty and Guides, with a CSS entrance only. For the security page of any app that remembers devices.

FAQ

How do I fill it with my own devices?

Edit DEVICES at the top. Each has an id, a name the person recognises, the browser and system as where, the ISO day it last signed in as used, and two booleans: code (it skips the sign-in code) and password (it also skips the password prompt, which only counts while code is true). LIMIT is how many devices an account may trust, and the meter and the count in the heading are worked out from the list. Never name a device model: name what the person would call it.

Why can the second switch be off and unavailable?

Skipping the password prompt before sensitive changes only makes sense on a device that also skips the code, since a device that always asks for a code is never fully trusted. So the second switch is disabled while the first is off, shows off, and the sentence under the table says it is unavailable while the code is asked. Turning the first off turns the second off too. Both switches are named for their device ("Skip the sign-in code on Phone").

What does the sentence under the table say?

It is written from the chosen device's two switches: for a device that skips both, that if it is lost someone could change the account's email without a code; for one that skips only the code, that someone with the password could sign in but sensitive changes still ask for it; for one that skips neither, that it asks for both. Changing a switch picks that device, so the sentence always describes what you just did. Edit consequenceOf to match the rules of your own product.

How does Forget work, and what stays local?

Pressing Forget swaps the button, in place, for Cancel and Confirm, with focus on Cancel; Escape or Cancel put the old button back, and Confirm removes the device from the list in the page, says so in the status line and moves focus to the next device. Nothing is sent and nothing is saved: the switches and the list live in the page. In your app, call your server in the handlers that change a device and in forget, and return a forgotten device to the sign-in prompt on its next visit.

Is it accessible?

It is a native table with a caption, column heads and a row head for each device, and every switch is named for both what it does and the device. The device name is a button that says whether it is chosen with aria-pressed; the table sits in a scrollable region that takes a tab stop, in case it ever has to scroll. Forget and its confirmation name the device, and one polite status line reports each change. The switches use checked and onCheckedChange.

How does it look on a phone?

The table keeps its markup and turns into one card per device: the name and where it was last used on top, then each switch on its own line with its label at the start, then Forget. The sentence under it has room for the longest of its three versions, so choosing a device never moves the page.

  • Pro

    Security Review Account

    Sessions and devices

    A security review in three sections, devices, recent sign-ins and sign-in methods, where each item is answered with Yes, this is mine or Remove, with a progress bar and a Finish button that waits for every answer.

  • Pro

    An account's two-factor methods as rows with their role, history and a Test that opens a code field in place, Make primary, a guarded Remove, and a Set up that opens a QR code, a key name or a number.

  • Pro

    An account's recovery options: four numbered ways back in, each with its state in words, a masked value, a quiet test and a one-field form to set it up, and a line that counts how many are ready.

  • Pro

    Backup Codes Account

    Sign-in methods

    An account's backup codes: ten one-time codes in a hairline grid with the spent ones struck through, a meter of how many are left, a real text file to download and copy, and a new set behind a password.

  • Pro

    Remember Device Login

    Sessions and devices

    A full-height sign-in page for an email client where trusting the browser is a choice with a consequence: a switch opens a 7, 30 or 90 day choice and a live line works out the date from a typed today.

  • Pro

    A panel of trusted devices for a smart-home app: each has a trust-expiry meter, Forget asks in an alert dialog, Undo brings the last one back and a Shine Button trusts this browser for 30 days.