shadcn.io is not affiliated with official shadcn/ui
Remember Device Login Block for React
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.
Installation
Overview
Make trusting a browser a choice people can read, with this remember device login block for React with Base UI. It's the sign-in of Mailkeel, an email client: the page's side rails run the full height of the screen and one band crosses it between two rules, with a start-aligned header over a hairline and two cells split by a divider. At the start sit a Field with an Input for the email and another with a Password Input. At the end, a "Trust this browser" Switch with its warning about shared computers opens a three-way Segment Group of 7, 30 or 90 days, a line that works the date out from a typed "today" ("You won't be asked for a code on this browser until Nov 13, 2026"), and the Shine Button that signs in, the only colored control. The choice's room is held, quiet while the switch is off, so nothing moves. The divider meets the hairline and the band's rule at plus marks, ruled by Guides. It's built from Switch, Segment Group, Field, Input, Password Input, Button, Shine Button and Guides, with a CSS entrance only. For any product that asks for a code on new browsers.
FAQ
What stays in the page, and what would a real product do?
Nothing is stored: no cookie is set and the choice is gone on reload. Sign-in waits under a spinner for less than a second, then shows "You're signed in", whether this browser is trusted and until when, and a polite status message says nothing was stored. A real product sets a signed, HttpOnly cookie only when trust is on, with an expiry the server checks, and skips the code step only while that cookie is valid. Post the form to your auth endpoint where the code says so.
How is the date worked out?
From a typed "today" (midnight UTC on 2026-10-14) plus the number of days, in UTC, and written with Intl.DateTimeFormat, so the server and every visitor's time zone print the same day. It never reads the clock when the page renders. In a product the server decides the expiry and sends the date back, and the page only prints it.
What about shared computers?
Trust starts off, so someone has to choose it, and the warning sits beside the switch where the choice is made. Beyond the page: make the cookie revocable from a list of trusted browsers in the account's settings, drop every trusted browser when the password changes or a security event happens, and ask for the password again before sensitive actions even on a trusted browser.
Why 7, 30 and 90 days?
They are common defaults, a week for caution, a month as the usual, and a quarter for a personal laptop; pick the set that matches how risky an unlocked mailbox is for your users. The choices are the DURATIONS array: each has its number of days, its label and a value, and the date line follows the one that is chosen.
Why is the 7, 30, 90 choice visible while trust is off?
Hiding it would leave a hole in the middle of a centered page, and revealing it would move the Sign in button under the pointer. It stays in place, quiet and out of reach of the keyboard, with no selected segment until the switch is on; then the choice wakes up with 30 days selected, and a polite message reads the new date out.
Why is the Sign in button never disabled?
A disabled button can't explain itself, and keyboard users can't reach it. Pressing Sign in with an empty or malformed email, or no password, marks those fields invalid, writes one sentence under each and moves focus to the first. Typing clears that field's problem, and each field keeps a line for its problem even when there is none.
Related
- Pro
Trusted Device Management Login
Sessions and devicesA 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.
- Pro
Device Approval Login
Codes and approvalsA sign-in screen with a drawn phone: it asks whether the request is you, shows three number buttons, approves the matching one, denies a wrong one and points Deny to a password change.
- Pro
Two-Factor Authenticator Login
Codes and approvalsA split sign-in step for an investing app: a six-digit code field beside a demo authenticator whose code and draining ring change every 30 seconds, where the current code and the one before it both sign in.
- Pro
Session Limit Login
Sessions and devicesA sign-in gate for a video streaming service: a meter of screens in use, three sessions as radio rows, and one button that ends the chosen session so this browser can continue.
- Pro
Centered Sign In Login
Centered formA full-height sign-in page for a team chat app: the product's mark, Google and GitHub rows with lettermark tiles, an or rule, email and password checked on submit, and one Sign in button with a simulated wait and its result.
- Pro
Session Expired Login
Sessions and devicesA re-authentication page for a document editor that keeps the email read-only, asks only for the password, shows where you were, and confirms before switching account.