Implement conditional create in Shrine #189
Conversation
Summary of ChangesHello @cy245, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces the capability for conditional passkey creation within the Shrine application. It refactors the existing authentication mechanism to support a unified username and password login, which then seamlessly allows for the creation of a passkey if the user has logged in with traditional credentials. This change improves the security and convenience of user authentication by promoting passkey adoption after a successful password-based sign-in. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request successfully implements conditional passkey creation after a password-based login, which is a great step towards encouraging passkey adoption. The refactoring of the login flow into a single API call is also a significant improvement for both code clarity and efficiency. I've identified a couple of potential issues related to error handling and a possible race condition in the UI flow that could lead to a confusing user experience. Addressing these points will make the implementation more robust.
| if (isPasswordCredential) { | ||
| viewModel.conditionalCreatePasskey( | ||
| createPasskeyOnCredMan = { createPasskeyRequestObj: JSONObject -> | ||
| credentialManagerUtils.createPasskey( | ||
| requestResult = createPasskeyRequestObj, | ||
| context = context, | ||
| isConditional = true, | ||
| ) | ||
| } | ||
| ) | ||
| } | ||
| createRestoreKey() | ||
| navigateToHome(flag) | ||
| navigateToHome(!isPasswordCredential) |
There was a problem hiding this comment.
When a user signs in with a password (isPasswordCredential is true), both viewModel.conditionalCreatePasskey() and createRestoreKey() are called. These functions trigger asynchronous credential creation flows that can run in parallel. This could lead to a confusing user experience with multiple system prompts for creating credentials appearing simultaneously, and may also cause race conditions. It would be better to make these calls mutually exclusive. For instance, you could offer to create a standard passkey after a password login, and offer to create a restore key after a passkey login.
if (isPasswordCredential) {
viewModel.conditionalCreatePasskey(
createPasskeyOnCredMan = { createPasskeyRequestObj: JSONObject ->
credentialManagerUtils.createPasskey(
requestResult = createPasskeyRequestObj,
context = context,
isConditional = true,
)
}
)
} else {
createRestoreKey()
}
navigateToHome(!isPasswordCredential)| is AuthResult.Success -> { | ||
| val createPasskeyResponse = createPasskeyOnCredMan(result.data) | ||
| if (createPasskeyResponse is GenericCredentialManagerResponse.CreatePasskeySuccess) { | ||
| repository.registerPasskeyCreationResponse(createPasskeyResponse.createPasskeyResponse) |
There was a problem hiding this comment.
The result of repository.registerPasskeyCreationResponse() is not being checked. This method returns an AuthResult which can indicate failure. If the server fails to register the passkey, this failure is silently ignored. This could lead to a state where a passkey exists on the device but is not usable because the server is unaware of it. It's important to handle the AuthResult.Failure case to ensure data consistency and aid in debugging.
val responseResult = repository.registerPasskeyCreationResponse(createPasskeyResponse.createPasskeyResponse)
if (responseResult is AuthResult.Failure) {
Log.e(TAG, "Failed to register conditional passkey with server: ${responseResult.error}")
}| } | ||
|
|
||
| is AuthResult.Failure -> { | ||
| Log.e(TAG, "Error during conditional passkey creation.") |
There was a problem hiding this comment.
The error message for a failed passkey creation request is quite generic. For better diagnostics and debugging, it would be helpful to include the specific error details from the AuthResult.Failure object in the log message.
Log.e(TAG, "Error during conditional passkey creation: ${result.error}")1 participant
Implements Conditional Create (also called Automatic Passkey Upgrade) in Shrine
Also fixes login function to use more correct server endpoint (original returns an empty object which was causing a bug).