shadcn.io is not affiliated with official shadcn/ui
Domain Routing Login Block for React
A sign-in page for workforce scheduling that reads the domain of your email and says how that company signs in: one required provider, a provider with a password option, a choice of two, or a password for a stranger.
Installation
Overview
Let the email decide how someone signs in, with this domain routing login block for React with Base UI. It's the sign-in page of Shiftloom, workforce scheduling: the page's side rails run the full height of the screen and one band crosses it between two rules, holding one centered column with a single Field. Under it a card answers from a typed list of four company rules as you type. A company that requires one provider gets that provider, a tile and a Required Badge and no password option; one that allows a password too says Optional and offers Use password instead; one with two providers becomes a choice of two, and the Shine Button, the only colored control, follows it ("Continue with Okta"). A domain on no list gets a password field once typing pauses. Why am I being redirected? opens a Popover with the reason, and the page keeps one height for every card. It's built from Field, Input, Password Input, Badge, Popover, Button, Shine Button and Guides, with a CSS entrance only. For scheduling, HR and any tool sold to companies that run their own identity provider.
FAQ
What stays in the page, and how do I wire real rules?
All of it. The four rules are a typed list, a provider press shows where a real sign-in would go and nothing redirects, and a password sign-in waits under a spinner and shows a result that says nothing was sent. In a product, look the domain up on your server when the email is submitted, return the company's rule (its providers and whether a password is allowed), and redirect with a SAML request or an OpenID Connect authorization request where the code says so. The three states of the card, one provider, a choice and no rule, are the three answers your lookup can give.
How is the domain read, and when does a stranger's domain get a password?
The card reads the text after the last @, lower-cased. A domain that matches a rule shows its provider at once. A domain that matches nothing waits until typing pauses for half a second, or the field loses focus, and then, if the address is a full one, the card turns into a password field with a sentence naming the domain. Until then it shows the hint, so a half-typed domain never gets a verdict.
What does Optional change?
It is the rule an admin chose when a company allows passwords next to single sign-on. The card says so and offers Use password instead, which swaps in a password field and a Sign in button; Use Google Workspace instead goes back. A Required rule has no such button, and the space where it would be is held so nothing moves.
How does a domain with two providers work?
Lowrie Logistics has staff on one provider and drivers and contractors on another, so the card becomes two native radio rows with the audience under each name. The first is chosen, and the button names the one in hand. They are plain radios named by their text, so the arrow keys move between them on every target.
Why is the button never disabled?
A disabled button can't explain itself and keyboard users can't reach it. Pressing it with an empty or malformed email marks the field invalid, writes one sentence under it and moves focus there; with a password card showing, an empty password does the same. Typing clears the problem, and each field keeps a line for its problem even when there is none.
What does the popover say, and does it work from the keyboard?
It says that an admin set a sign-in rule for the domain, that the page reads the domain after the @ and sends everyone at it to the same place, and whether passwords are on or off for it. It opens from the keyboard, Escape closes it and focus returns to the link that opened it. It appears only on a card that has a rule to explain, and the room is held when it doesn't.
Related
- Pro
Enterprise SSO Login
SSO and providersA sign-in page for a construction project manager that asks for the workspace address first: it looks the workspace up as you type, offers the right spelling for a typo and turns the button into Continue with SSO.
- Pro
Identity Provider Login
SSO and providersA searchable list of ten sign-in providers in three groups with counts and a Connected before marker: typing filters, Enter or a press chooses, the button names the choice and shows where a real sign-in would go.
- Pro
Email First Sign In Login
Step by stepAn identifier-first sign-in for an invoicing app: one email field, a lookup against two typed accounts, then either the password step with the address kept as a badge or account creation with the address carried over.
- Pro
Federated Identity Login
SSO and providersA provider chooser for a cloud console: a table of five identity providers with protocol, a health word and dot, and the last check, where a provider in maintenance can't be chosen and says why, and one button connects.
- Pro
SAML Redirect Login
SSO and providersA sign-in page for payroll that walks through a SAML hand-off one step at a time: five read-only steps, a Now at address, Start redirect, Step and Cancel, and the facts and typed request the two sides agree on.
- Pro
LDAP Directory Login
SSO and providersA sign-in page for a company intranet against its directory: a choice of directory where DEV is offline with its reason, a second choice between DOMAIN user and user at domain that rewrites the field, and the server facts beside it.