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

chore: Expose account keys #144

Merged
merged 2 commits into from
Jul 12, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion workspaces/src/types/account.rs
Original file line number Diff line number Diff line change
@@ -3,7 +3,7 @@ use std::path::Path;

use near_primitives::views::AccountView;

use crate::types::{AccountId, Balance, InMemorySigner};
use crate::types::{AccountId, Balance, InMemorySigner, SecretKey};
use crate::{CryptoHash, Network, Worker};

use crate::operations::{CallTransaction, CreateAccountTransaction, Transaction};
@@ -147,6 +147,11 @@ impl Account {

Ok(())
}

/// Get the keys of this account. The public key can be retrieved from the secret key.
pub fn keys(&self) -> SecretKey {
SecretKey(self.signer.0.secret_key.clone())
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it is fine to only return SecretKey, but I would argue that keys is not a good name in this case because of plurality. Maybe just key or secret_key while leaving the clarification that public key can be retrieved from the secret key?

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, noting it's probably best if we keep this representation internally, and then this method can return &SecretKey. Cloning implicitly feels weird

Copy link
Member Author

Choose a reason for hiding this comment

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

Gotcha, I'll re-work how InMemorySigner is represented internally but shouldn't be too big of a deal to expose it as a &SecretKey

Copy link
Member Author

Choose a reason for hiding this comment

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

alright should be good. Ready to be re-reviewed whenever you guys get the chance

}

// TODO: allow users to create Contracts so that they can call into
2 changes: 1 addition & 1 deletion workspaces/src/types/mod.rs
Original file line number Diff line number Diff line change
@@ -73,7 +73,7 @@ impl PublicKey {
/// to form a keypair associated to the account. To generate a new keypair, use
/// one of the creation methods found here, such as [`SecretKey::from_seed`]
#[derive(Debug, Clone, Eq, PartialEq, Serialize, Deserialize)]
pub struct SecretKey(near_crypto::SecretKey);
pub struct SecretKey(pub(crate) near_crypto::SecretKey);

impl SecretKey {
pub fn key_type(&self) -> KeyType {