Closed tcannonfodder closed 1 year ago
As part of the discussion for devise-passkeys, it became clear that Warden::WebAuthn::StrategyHelpers was being included in places that extend beyond its intended purpose. (see: https://github.com/ruby-passkeys/devise-passkeys/pull/25#issuecomment-1605239266)
devise-passkeys
Warden::WebAuthn::StrategyHelpers
A major cause of that was the relying_party_key method, which devise-passkeys was using to add the relying party to the request ENV.
relying_party_key
In order to keep the two gems separated cleanly (to reduce conflicts like this), we need to:
Warden::WebAuthn::RackHelpers
As part of the discussion for
devise-passkeys, it became clear thatWarden::WebAuthn::StrategyHelperswas being included in places that extend beyond its intended purpose. (see: https://github.com/ruby-passkeys/devise-passkeys/pull/25#issuecomment-1605239266)A major cause of that was the
relying_party_keymethod, whichdevise-passkeyswas using to add the relying party to the request ENV.In order to keep the two gems separated cleanly (to reduce conflicts like this), we need to:
relying_party_keyinto a newWarden::WebAuthn::RackHelpersmoduleWarden::WebAuthn::StrategyHelpersto achieve the same goal of a centrally located default key