feat(elements): Add support for sign in with passkey by panteliselef · Pull Request #3472 · clerk/javascript

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

panteliselef · 2024-05-30T18:39:34Z

Description

This PR add support for passkey usage within a SignIn flow

APIs introduced:

<SignIn.Passkey />
<SignIn.SupportedStrategy name='passkey'>
<SignIn.Strategy name='passkey'>
<Clerk.Input type='text' passkeyAutofill>

Usage Examples:

<SignIn.Passkey />

<SignIn.Stepname='start'><SignIn.Passkey><Clerk.Loading>{isLoading=>(isLoading ? <Spinner/> : 'Use passkey instead')}. </Clerk.Loading></SignIn.Passkey></SignIn.Step>

<SignIn.SupportedStrategy name='passkey'>

<SignIn.SupportedStrategyasChildname='passkey'><Button>use passkey</Button></SignIn.SupportedStrategy>

<SignIn.Strategy name='passkey'>

<SignIn.Strategyname='passkey'><pclassName='text-sm'>
Welcome back <SignIn.Salutation/>!
</p><CustomSubmit>Continue with Passkey</CustomSubmit></SignIn.Strategy>

<Clerk.Input type='text' passkeyAutofill>

<SignIn.Stepname='start'><Clerk.Fieldname='identifier'><Clerk.LabelclassName='sr-only'>Email</Clerk.Label><Clerk.InputpasskeyAutofillplaceholder='Enter your email address'/><Clerk.FieldError/></Clerk.Field>
</SignIn.Step/>

Docs PR: clerk/clerk-docs#1132

Checklist

npm test runs as expected.
npm run build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
(If applicable) Documentation has been updated

Type of change

changeset-bot · 2024-05-30T18:39:37Z

🦋 Changeset detected

Latest commit: d16809f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@clerk/elements	Minor
@clerk/clerk-js	Minor
@clerk/shared	Minor
@clerk/chrome-extension	Patch
@clerk/clerk-expo	Patch
@clerk/backend	Patch
@clerk/express	Patch
@clerk/fastify	Patch
@clerk/nextjs	Patch
@clerk/clerk-react	Patch
@clerk/remix	Patch
@clerk/clerk-sdk-node	Patch
@clerk/testing	Patch
@clerk/ui	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

panteliselef · 2024-05-30T18:41:26Z

+ case 'passkey': {
+ return await parent.getSnapshot().context.clerk.client.signIn.authenticateWithPasskey();
+ }


When "Submit" is hit we don't want to call attempt, instead call authenticateWithPasskey

panteliselef · 2024-05-30T18:42:04Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Should this be handled inside an actor ?

Which part are you referring to?

Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

This is only necessary if we want to support passkey autofill.

Should we rely on "the platform" here? It doesn't feel necessary to create a separate abstraction if all it takes is specifying a native property on the element, unless we need to execute some specific logic to enable autofill.

We also need to call authenticateWithPasskey internally

panteliselef · 2024-05-30T18:55:46Z

+ on: {
+ 'AUTHENTICATE.PASSKEY': {
+ guard: not('isExampleMode'),
+ target: 'AttemptingPasskey',
+ reenter: true,
+ },
+ SUBMIT: {
+ guard: not('isExampleMode'),
+ target: 'Attempting',
+ reenter: true,
+ },
+ },


Enabling "autofill" is kind of fire and forget action, so we should be able to recover from this state and not get stuck. Promise will await until user interact with the field and select a passkey and that may never happen.

brkalow

Looking good. I'd like to see the passkey specific logic moved out of the input logic.

brkalow · 2024-06-03T13:47:16Z

+ const [isSupported, setIsSupported] = React.useState(false);
+ React.useEffect(() => {
+ async function runAutofillPasskey() {
+ const _isSupported = await isWebAuthnAutofillSupported().catch(() => false);
+ setIsSupported(_isSupported);
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ if (passthroughProps?.passkeyAutofill) {
+ runAutofillPasskey();
+ }
+
+ // @ts-expect-error - Depending on type the props can be different
+ }, [passthroughProps?.passkeyAutofill]);


Yeah, passkey specific logic shouldn't live in the common input element like this. Let's try to move it to an actor.
Why does passkeyAutofill need to be on the input?

brkalow

Looking good. Let's move the logic from the component into useInput() to keep the component layer thin.

Any ideas for not referencing the sign in flow actor directly in the common input components?

brkalow · 2024-06-05T15:23:38Z

+ React.useEffect(() => {
+ if (passkeyAutofillSupported) {
+ signInRouterRef?.send({ type: 'AUTHENTICATE.PASSKEY.AUTOFILL' });
+ }
+ }, [passkeyAutofillSupported, signInRouterRef]);


Can this be in the useInput() hook? Ideally the components here are just thin wrappers around the hook, which contains the business logic

Probably yes, but if felt like something only this component should care about.
because we are using refs here and not the context, it will not error, but i thought it would ok to not litter useInput with sign in specific logic.

Turns out with the current setup this is a bit hard. useSignInPasskeyAutofill will use the useSelector underneath which would error when the SignInRouter context is not available.

brkalow · 2024-06-05T15:24:14Z

 (props: FormInputProps, forwardedRef) => {
 const clerk = useClerk();
+ const passkeyAutofillProp = (props as PasskeyInputProps).passkeyAutofill;
+ const signInRouterRef = SignInRouterCtx.useActorRef(true);


I'm not crazy about referencing the sign in actor directly in these components, but not sure if there's another way. 🤔
Maybe @tmilewski has an idea?

Is this better ?
<SignIn.Passkey><Clerk.Input/></SignIn.Passkey>

I can see issues with that as well, because SignIn.Passkey wouldn't know whether it needs to pass the autofill prop or not. To avoid leaking the prop to the dom for everything else, but only pass it to Clerk.Input.
Another thought is to have a SignIn.PasskeyInput, but this does not feel right.

We are now simply detecting autoComplete="webauthn"

brkalow · 2024-06-10T21:50:14Z

+ const field = useInput(props);
+
+ const hasPasskeyAutofillProp = Boolean(field.props.autoComplete?.includes('webauthn'));
+ const allowedTypeForPasskey = (['text', 'email'] as FormInputProps['type'][]).includes(field.props.type);


Should we consider tel here for phone numbers?

I think you are correct

brkalow

👍

clerk-cookie added the elements label May 30, 2024

panteliselef commented May 30, 2024
View reviewed changes

Comment threadpackages/elements/src/internals/machines/sign-in/utils/starting-factors.ts Outdated

panteliselef commented May 30, 2024
View reviewed changes

Comment threadpackages/elements/src/internals/machines/sign-in/verification.machine.ts Outdated

panteliselef commented May 30, 2024
View reviewed changes

Comment threadpackages/elements/src/react/common/form/index.tsx Outdated

panteliselef changed the title ~~Elef/passkey elements~~feat(elements): Add support for sign in with passkeyMay 30, 2024

panteliselef commented May 30, 2024
View reviewed changes

Comment threadpackages/elements/src/internals/machines/sign-in/router.machine.ts Outdated

panteliselef commented May 30, 2024
View reviewed changes

Comment threadpackages/elements/src/internals/machines/sign-in/router.machine.ts Outdated

panteliselef self-assigned this May 31, 2024

panteliselef marked this pull request as ready for review May 31, 2024 09:48

panteliselef requested review from LekoArts, brkalow and tmilewski May 31, 2024 09:51

tmilewski reviewed May 31, 2024
View reviewed changes

LekoArts reviewed Jun 3, 2024
View reviewed changes

Comment threadpackages/elements/src/react/common/form/index.tsx Outdated

LekoArts reviewed Jun 3, 2024
View reviewed changes

Comment threadpackages/elements/src/react/common/form/index.tsx Outdated

LekoArts reviewed Jun 3, 2024
View reviewed changes

Comment threadpackages/elements/src/react/sign-in/action/passkey.tsx

brkalow requested changes Jun 3, 2024
View reviewed changes

panteliselef added 9 commits June 3, 2024 19:07

feat(elements): Add support for sign in with passkey
e70b37d

feat(elements): Input field with passkey autofill
c2d7611

feat(elements): Handle submit attempts when attempting passkey autofill
69e387f

chore(elements): Remove redundant types
ac84712

chore(elements): Improve code readability
4af33d8

chore(elements): Add changeset
d12ecec

fix(elements): Add missing file
f830e31

chore(elements): Use dot notation for event type
51d7def

chore(elements): Introduce isNonPreperableStrategy
01c42bf

chore(shared,clerk-js,elements): Move webauthn utilities to shared
4737f40

panteliselef force-pushed the elef/passkey-elements branch from fb140bc to 4737f40Compare June 3, 2024 16:43

clerk-cookie added the clerk-js label Jun 3, 2024

panteliselefand others added 6 commits June 3, 2024 19:44

Merge branch 'refs/heads/main' into elef/passkey-elements
d1ed9a9

chore(elements): Sanitize props
7db4a1b

chore(elements): Make passkey a standalone component
0122832

chore(elements): Update changeset
4c9e102

chore(elements): Move autofill support detection inside an actor
6fadabd

adjust changeset
376190d

LekoArts reviewed Jun 5, 2024
View reviewed changes

Comment threadpackages/elements/src/react/common/form/index.tsx Outdated

LekoArts reviewed Jun 5, 2024
View reviewed changes

Comment threadpackages/elements/src/react/sign-in/action/action.tsx Outdated

LekoArts reviewed Jun 5, 2024
View reviewed changes

Comment threadpackages/elements/src/react/sign-in/passkey.tsx Outdated

panteliselef added 3 commits June 5, 2024 14:19

Address PR comments
12e6257

Address tests failing
f899070

Improve error handling
0f5c3e3

brkalow reviewed Jun 5, 2024
View reviewed changes

panteliselef added 3 commits June 6, 2024 20:14

chore(elements): Drop passkeyAutofill and depend on webauthn
1d3344e

Merge branch 'main' into elef/passkey-elements
32344a9

chore(*): Update changeset
3a0356d

brkalow reviewed Jun 10, 2024
View reviewed changes

brkalow approved these changes Jun 10, 2024
View reviewed changes

panteliselef added 2 commits June 11, 2024 10:59

chore(elements): Detect webauthn in with type tel
88477f4

Merge branch 'main' into elef/passkey-elements
d16809f

panteliselef enabled auto-merge (squash) June 11, 2024 08:02

panteliselef merged commit 4ec3f63 into mainJun 11, 2024

panteliselef deleted the elef/passkey-elements branch June 11, 2024 08:16

This was referenced Jun 11, 2024
ci(repo): Version packages #3530
Closed
ci(repo): Version packages #3554
Merged

LekoArts mentioned this pull request Jun 13, 2024
feat(elements): Use passkey with elements for sign in clerk/clerk-docs#1132
Merged