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

feat(wallets): restrict wallet creation with allow_registrations flag #2203

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

CharlVS
Copy link
Member

@CharlVS CharlVS commented Aug 28, 2024

KDF startup throws an error if the allow_registrations config value is false and the seed is unknown (no name provided) or if a name is provided and it has not been registered before. Defaults to true (current dev behaviour)

This is used to emulate the sign-in vs register behaviour a typical auth service would provide.

TODO: Tests

KDF startup throws an error if the `allow_registrations` config value is false and the seed is unknown (no name provided) or if a name is provided and it has not been registered before.

This is used to emulate the sign-in vs register behaviour a typical auth service would provide.
@CharlVS CharlVS added the in progress Changes will be made from the author label Aug 28, 2024
@CharlVS CharlVS self-assigned this Aug 28, 2024
@CharlVS CharlVS changed the title feat(wallets): Restrict wallet creation with allow_registrations flag feat(wallets): Restrict wallet creation with allow_registrations flag Aug 28, 2024
@CharlVS CharlVS changed the title feat(wallets): Restrict wallet creation with allow_registrations flag feat(wallets): restrict wallet creation with allow_registrations flag Aug 28, 2024
@CharlVS
Copy link
Member Author

CharlVS commented Aug 28, 2024

@takenagain can you please assist with writing tests for this while I focus on other GUI tasks?

mm2src/mm2_main/src/lp_wallet.rs Outdated Show resolved Hide resolved
@CharlVS
Copy link
Member Author

CharlVS commented Sep 2, 2024

@takenagain please also review borngraced's feedback about redundant comments and snip them.

Comment on lines 275 to +278
// Importing an encrypted passphrase without a wallet name is not supported since it's not possible to save the passphrase.
(None, Some(Passphrase::Decrypted(passphrase))) => {
if ctx.allow_registrations() {
Ok(Some(passphrase))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to understand the need of allow_registrations here, this is the legacy approach where we pass a passphrase without a wallet name, so no wallet is created from KDF side here.

I understand the need for it in other places, although I think it's redundant, it can have benefits from GUI side for clear paths between registrations and login but GUI should never allow it's users to hit an error from KDF side such as WalletInitError::WalletCreationNotAllowed if I understand correctly. So, I don't think I also understand it's need in other places :)

I will take over this PR and it's fixes once I understand the need for this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shamardy I'm fine leaving this part out because it won't be used in our GUI, but it will mean we have to entirely deprecate non-name wallet logins in the KDF SDK I'm working on. However, leaving this in will allow both register and sign-in for non-name wallets, giving devs more flexibility to use the SDK as they wish. From what I can tell, there is no downside for us.

Either way, I'll work with whatever your call is. It's worth noting that this slightly akin to the anonymous login offered by conventional auth services like Firebase Auth and Supabase Auth.

Copy link
Collaborator

@shamardy shamardy Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but it will mean we have to entirely deprecate non-name wallet logins in the KDF SDK I'm working on

non-name wallet logins still work the same way as before (before adding seed/mnemonic management in KDF) by just providing a passphrase with no wallet_name or wallet_password.

Copy link
Member

@onur-ozkan onur-ozkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KDF startup throws an error if the allow_registrations config value is false and the seed is unknown (no name provided) or if a name is provided and it has not been registered before. Defaults to true (current dev behaviour)

When did we add allow_registrations to the config file? I can't recall this field and it doesn't exist anywhere in the project. 🤔

Comment on lines +29 to +32
// Check if the wallet file already exists
if !wallet_path.exists() {
// If it doesn't exist and registrations are not allowed, return an error
if !ctx.allow_registrations() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can avoid the nested scope with:

Suggested change
// Check if the wallet file already exists
if !wallet_path.exists() {
// If it doesn't exist and registrations are not allowed, return an error
if !ctx.allow_registrations() {
// Handle the case when the wallet file does not exist, and registrations are not allowed.
if !wallet_path.exists() && !ctx.allow_registrations() {

Comment on lines +106 to +115
// Check if the wallet already exists
let existing_wallet = table
.get_item_by_unique_index("wallet_name", wallet_name.to_string())
.await?;

if existing_wallet.is_none() && !ctx.allow_registrations() {
return Err(MmError::new(WalletsDBError::Internal(
"Wallet creation is not allowed. Registrations are disabled.".to_string(),
)));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would guard this logic with if !ctx.allow_registrations() to query the wallet table only when it's necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in progress Changes will be made from the author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants