-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[PM-7382] Add support for non-UUID credential #11993
Conversation
Technically this deviates from the specification, but nobody is going to be using the authenticator directly but us so it shouldn't matter. We're gonna switch to `passkey-rs` anyways so
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## main #11993 +/- ##
==========================================
+ Coverage 33.48% 33.49% +0.01%
==========================================
Files 2844 2845 +1
Lines 89044 89057 +13
Branches 16987 16990 +3
==========================================
+ Hits 29812 29827 +15
+ Misses 56887 56885 -2
Partials 2345 2345 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
Fixed Issues
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this after modifying the makeKey
logic to produce a b64 credentialId
and it seems to work. The passkey also worked on the native iOS app, so I think we're good with this approach.
@@ -64,7 +64,7 @@ export class Fido2AuthenticatorError extends Error { | |||
} | |||
|
|||
export interface PublicKeyCredentialDescriptor { | |||
id: BufferSource; | |||
id: Uint8Array; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General question, should be interface be prescriptive enough about the ID to define it as Uint8Array
, or use ArrayBuffer
? I don't see an issue sticking with Uint8Array
though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually commented this in the commit. I don't think it matters
refactor: change interface to use Uint8Array for simplification
Technically this deviates from the specification, but nobody is going to be using the authenticator directly but us so it shouldn't matter. We're gonna switch topasskey-rs
anyways so
|
||
export function parseCredentialId(encodedCredentialId: string): Uint8Array { | ||
try { | ||
if (encodedCredentialId.startsWith("b64.")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hate it, but let's run with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100% agree
/** | ||
* Compares two credential IDs for equality. | ||
*/ | ||
export function compareCredentialIds(a: Uint8Array, b: Uint8Array): boolean { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may benefit from having a general util function for comparing Uint8Arrays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah but you've always stopped me when adding functions to the general utils in the past so now I'm going by "if we use it twice put it in general" XD
🎟️ Tracking
📔 Objective
Implement support for
credentialIds
encoded as Base64. This does not change how newcredentialIds
are created, this is on purpose so that we don't break older clients📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes