fix: do not offer sign-up on an instance whose sign-up mode does not allow it - #453
Open
dbeattie71 wants to merge 1 commit into
Open
fix: do not offer sign-up on an instance whose sign-up mode does not allow it#453dbeattie71 wants to merge 1 commit into
dbeattie71 wants to merge 1 commit into
Conversation
`ClerkAuthentication` renders the "Don't have an account? Sign up" toggle unconditionally, so on a `restricted` or `waitlist` instance it offers an account it cannot create. Filling in the form it leads to ends in the API refusing the sign-up — an affordance whose only outcome is a rejection. Observed on a production instance whose access mode is Invite-only: the signed-out screen renders a full sign-up form, First name through Password, for an instance that accepts none of it. The mode is already here. `user_settings.sign_up.mode` is parsed into `SignUpSettings.mode` and reachable as `Auth.env.user.signUp.mode`; nothing consulted it. `Environment.signUpIsOpen` names the question next to `hasOauthStrategies`, which the same `build` already reads for the OAuth panel, so the widget needs no new dependency to answer it. Strict on purpose: only `public` reads as open. `restricted` requires an invitation and `waitlist` collects an address for later, and this SDK implements neither flow, so on those instances the form cannot succeed. An unrecognised value is likelier to be a mode this does not know about than a reason to offer an account to everyone. **Only the toggle is gated, never the panel.** If something has already put the auth state into signing-up, `ClerkSignUpPanel` still renders: a sign-up in flight must not become a blank card, and hiding a form somebody is part-way through is a worse failure than showing one that is refused. `_state` starts at `signingIn` and, with no toggle, only the existing coercion from `authState.isSigningUp` can move it.
dbeattie71
force-pushed
the
fix/respect-sign-up-mode
branch
from
September 10, 2026 03:06
2af7f73 to
70371e4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
ClerkAuthenticationrenders the "Don't have an account? Sign up" toggle unconditionally, so ona
restrictedorwaitlistinstance it offers an account it cannot create. Filling in the form itleads to ends in the API refusing the sign-up — an affordance whose only possible outcome is a
rejection.
Observed on a production instance whose access mode is Invite-only: the signed-out screen
renders a full sign-up form, First name through Password, for an instance that accepts none of it.
The mode is already parsed — nothing consulted it
user_settings.sign_up.modeis read intoSignUpSettings.modeand reachable asAuth.env.user.signUp.mode. This addsEnvironment.signUpIsOpenbesidehasOauthStrategies, and_ClerkAuthenticationState.buildalready readsauthState.envfor the OAuth panel — so the widgetneeds no new dependency to answer the question.
Two deliberate choices
Only
publicreads as open.restrictedrequires an invitation andwaitlistcollects anaddress for later; the SDK implements neither flow, so on those instances the form cannot succeed.
An unrecognised value is far likelier to be a mode this getter has not heard of than a reason to
offer an account to everyone — so it fails closed.
Only the toggle is gated, never the panel. If something has already put the auth state into
signing-up,
ClerkSignUpPanelstill renders. A sign-up in flight must not become a blank card, andhiding a form somebody is part-way through would be a worse failure than showing one that is
refused.
_statestarts atsigningInand, with no toggle, only the existing coercion fromauthState.isSigningUpcan move it — so nothing that works today stops working.Tests
Three cases added to
environment_test.dart, following thehasOauthStrategiesgroup:publicisopen;
restrictedandwaitlistare not; an unknown mode, an empty mode andEnvironment.emptyare not.
dart testgreen onclerk_auth,flutter analyzeclean onclerk_flutter(onepre-existing
unnecessary_importinfo in an unrelated test file).Alternative considered
A
signInOnlyparameter on the widget. Rejected: the widget's whole design is to take noparameters and read the instance instead, and the instance already states this. A caller should not
have to restate what Clerk has already said.