Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signups when UVPA doesn't exist #83

Open
zespere opened this issue Sep 8, 2024 · 2 comments
Open

Signups when UVPA doesn't exist #83

zespere opened this issue Sep 8, 2024 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@zespere
Copy link
Contributor

zespere commented Sep 8, 2024

If device doesn't support passkeys i want to sign user up and sent him account confirmation email and then do the same every time he signs in, how should i approach doing this?

@type1fool

@zespere zespere changed the title Signups when UVPA is false Signups when UVPA doesn't exist Sep 8, 2024
@type1fool type1fool self-assigned this Sep 28, 2024
@type1fool type1fool added the question Further information is requested label Sep 28, 2024
@type1fool
Copy link
Collaborator

The SupportComponent will send a {:passkeys_supported, false} message to the parent LiveView in that case. With this message, you might set a @passkeys_supported? assign, which would be used to remove the webauthn components in the template. Email magic links seem like a sensible fallback, and there are several articles online for implementing magic link authentication in Phoenix.

If you have used the mix wac.install task or have a functioning LiveView for registration and authentication, it may be relatively straightforward to implement magic links as a fallback. This is a feature that would be nice to include in the code generated by wac.install, though I have some hesitation that it will lead to requests for other fallbacks and configurability that may be hard to support. The results for passwordless on hex.pm don't give me much confidence about including them in this package.

At a glance, ueberauth_passwordless seems like a decent starting point. I've had good success with ueberauth_google on a project recently.

@zespere
Copy link
Contributor Author

zespere commented Sep 30, 2024

Thanks, i will soon provide feedback on how the implementation went once i solve my previous issue.

And regarding builtin "magic links as a fallback" feature, while ease of implementation of that feature is a valid reason not to make it builtin, i don't think people requesting more features is. You can just close the PRs/issues as it is your project and you are entitled to doing anything you want to do with it.

And if someone really wants some feature that badly, there's always a "fork" button.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants