require_email_and_passkey_label should not run for `:create` without a passkey

[asavageiv]

First off, thank you very much for this project! I can't wait to have passkeys replace passwords everywhere.

The problem for now is that we need to keep allowing sign up with passwords along side passkeys, but the before_action :require_email_and_passkey_label in RegistrationsControllerConcern prevents that because password signups of course don't pass that validation.

In general, it would be good for this to play nicely alongside password based authentication, so we should probably also avoid calling create_passkey_for_resource if we aren't doing passkey based registration.

What do you think about having something like this:

before_action :require_email_and_passkey_label, only: %i[new_challenge]
before_action :require_email_and_passkey_label, if: passkey_create?, only: %i[create]

def create
  super do |resource|
    create_passkey_for_resource(resource: resource) if passkey_create?
  end
end

def passkey_create?
  params&.dig(:action) == "create" && params&.dig(resource_name, :passkey_credential).present?
end

[tcannonfodder]

Hey Alan!

Great points here! However, I do think that this library should just be focused on the passkey-only authentication flow (to help keep it tightly focused, and nudge people off the edge to actually go full passkeys; it'll only happen when we make the leap!)

The great news is that:

• The actual webauthn authentication strategy lives in its own gem, https://github.com/ruby-passkeys/warden-webauthn
• The code here is very straightforward because it is focused (really, it's just a shim around that warden strategy)
• Since this gem leans heavily into concerns & modules, you have flexibility on how the controller actions are defined & utilized
• With those factors, incorporating passkeys alongside your existing password-based flows is definitely doable! Whether that's extracting the code you need to shim around warden-webauthn or sidestepping in your implementation.

Closing this as a "not planned" for this library; but definitely happy to keep the conversation going about the logistics of incorporating passkeys into password-based flows to help get folks secretly ready for passkeys