Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Device Approval Login Block for React

A 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.

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

Show what the other half of an approval looks like, with this device approval login block for React with Base UI. It's the sign-in screen of Thermowick, a smart-thermostat app: a whole screen with the page's rails and one band across it, a header that says which number this screen shows (47), and under it a drawn phone screen of the product's own interface, with no frame around it, labelled Phone. The phone asks "Is this you?" with the device, the place and a fixed time, three number buttons (23, 47 and 81) and a Deny button. Tapping 47 approves, another number says it does not match and denies the request, and Deny points to a password change; each result takes the phone's place in the same space, in words with a glyph and no colour. The one Shine Button under the phone follows the request: quiet while it waits, then Continue, Send a new request or Change your password. It's built from Button, Shine Button and Guides, with a CSS entrance only. For sign-ins that a trusted phone has to approve.

FAQ

What stays in the page, and how do I wire it for real?

Everything. The device, the place, the time and the number are typed constants, each choice waits half a second and changes the page's state, and nothing is sent to a phone or read from one. In a product, create a request on your server when the sign-in starts, with a random two-digit number, show that number on the sign-in screen and push the request to the person's enrolled phone with the device and place your server saw. The phone shows the real number and two others; your server checks the choice, keeps the request single-use and short-lived, and only then lets the sign-in continue.

Why three numbers, and why does a wrong one deny the request?

Because a plain Approve button is easy to press without reading, and a person who gets a request they did not start would approve it by habit. With number matching they have to find the number that only the real sign-in screen shows. A wrong number is treated as a sign that the request is not theirs, so the request ends and a new one has to be sent.

Why is the big button quiet while the phone waits?

Nothing can be done from the sign-in screen yet. A disabled button explains nothing and is skipped by the keyboard, so this one stays focusable: pressing it says what is missing ("Tap 47 there to approve") and moves focus to the first number on the phone. Once the request has an ending, the button names the next step: Continue to Thermowick, Send a new request or Change your password.

How are the results told apart without colour?

By a glyph and a word in the same space: a tick with "Approved", a cross with "Request denied" or "Denied", each with one sentence under it. The page uses no green or red. The result takes focus on its heading, and the page's one status line says the same thing for screen readers.

Is the phone a real phone frame, and what happens on a small screen?

No. It's a rounded greyscale panel of the product's own interface, at most 17rem wide, with no bezel, notch or status bar. On a phone the Phone label and the caption become screen-reader text and the Requested row drops out, so the button stays on the first screen.

Is it usable with a keyboard and a screen reader?

Yes. Each number is a real button named by its digits, so Tab and Enter work and the phone is a figure named Phone. While a choice is being checked the other buttons stay in place but do nothing, and the unused pane is inert so it cannot take focus. Start over is always there and says so when there is nothing to start over yet.

  • Pro

    An approval step for a freight dashboard: choose Push, Text or Call, send the request and match the number on screen with two demo buttons that play the phone, with a 60-second timer, a wrong-number cancel and an expiry.

  • Pro

    A 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

    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.

  • Pro

    A split sign-in page that asks whether a sign-in from far away was you: a drawn map with two places and an arc, a list of facts, and two answers, This is me and Not me.

  • Pro

    A page that reports a blocked sign-in after the fact: an incident timeline of three events, the facts of the attempt, then Secure my account (which asks for the password) or This was me.

  • 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.