-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add ACL to near-token-factory #24
base: main
Are you sure you want to change the base?
Conversation
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.
Regarding the CI failure: It might be related to new
of near-token-contract
now having an input parameter.
near-token-factory/src/lib.rs
Outdated
/// Account id that will be used as admin for all deployed tokens. | ||
token_admin: AccountId, |
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.
This probably requires extra care to not get out of sync with Contract.__acl
which stores internal Acl state:
In particular, Acl allows multiple admins and grantees for AclRole::UpdateTokenAdmin
, though Contract
can have only a single token_admin
. Could that lead to conflicts?
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.
Is there any way to access super-admins? I couldn't find any way right now. Anyway, having an explicit super-admin might still make sense, since this will be for the individual contracts and not for the factory.
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.
Good point, acl_get_super_admins
is missing. I'll prepare a PR to add it to near-plugins
.
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.
As agreed in our discussion, renamed the field token_super_admin to reflect its intention and be aligned with the naming used in near-plugins. Fixed in 6dc7d48
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.
After #20 was merged this PR's base branch was changed from acl
to main
. Maybe that caused some issues with the diff (see comment below)?
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.
The diff makes sense after the rebase. I've left some comments below.
// Grant MetadataUpdater role to the factory. This enables a trustless setup to set | ||
// the metadata by any user. Super admin is responsible for adding a new user account | ||
// with this role to provide icon and extra metadata. |
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.
// Grant MetadataUpdater role to the factory. This enables a trustless setup to set | |
// the metadata by any user. Super admin is responsible for adding a new user account | |
// with this role to provide icon and extra metadata. | |
// Grant MetadataUpdater role to the factory. This enables a trustless setup as | |
// described in [`Self::update_metadata`]. |
I think the description of update_metadata
is a bit easier to follow than the comment here.
Anyway, maybe we want to describe the idea only in one place? Then there's no risk of two descriptions getting out of sync.
#[near_bindgen] | ||
#[derive(BorshSerialize, BorshDeserialize, PanicOnDefault)] | ||
pub struct Contract { | ||
/// Account id of the engine. It is expected to be `aurora`. | ||
aurora: AccountId, | ||
/// Account id that will be used as super admin for all deployed tokens. |
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.
/// Account id that will be used as super admin for all deployed tokens. | |
/// Account id that will be used as super admin for newly deployed tokens. |
Nit but I think all can be misleading since changing token_super_admin
doesn't affect tokens that were already deployed (see doc comment of replace_token_admin
).
// Initialize Acl permissions. | ||
require!( | ||
contract.acl_init_super_admin(super_admin.clone()), | ||
"Failed to add factory as initial acl super-admin", |
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.
"Failed to add factory as initial acl super-admin", | |
"Failed to initialize acl super admin", |
It might be an account other than the factory if input parameter super_admin
is Some(account_id)
.
/// Initializes the contract. The locker account id MUST be the NEAR | ||
/// representative of the Aurora address of the locker contract created | ||
/// using the Cross Contract Call interface. |
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.
Should the doc comment describe what's happening in terms of Acl?
require!(contract | ||
.acl_grant_role(AclRole::TokenBinaryUpdater.into(), super_admin.clone()) | ||
.unwrap_or_default()); |
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.
require!(contract | |
.acl_grant_role(AclRole::TokenBinaryUpdater.into(), super_admin.clone()) | |
.unwrap_or_default()); | |
require!( | |
contract | |
.__acl | |
.grant_role_unchecked(AclRole::TokenBinaryUpdater, &super_admin), | |
"Failed to grant AclRole::TokenBinaryUpdater", | |
); |
This call of acl_grant_role
succeeds only if the contract itself is super admin or admin for TokenBinaryUpdater
. Neither of it holds if input parameter super_admin
is Some(other_account_id)
.
require!(contract | ||
.acl_grant_role(AclRole::TokenControllerUpdater.into(), super_admin) | ||
.unwrap_or_default()); |
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.
Same here, it should call grant_role_unchecked
too.
/// so all deployed contracts SHOULD be upgraded after calling this function. ONLY the | ||
/// `Owner` role can call this method. |
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.
/// so all deployed contracts SHOULD be upgraded after calling this function. ONLY the | |
/// `Owner` role can call this method. | |
/// so all deployed contracts SHOULD be upgraded after calling this function. | |
/// | |
/// Only accounts that are granted [`AclRole::TokenBinaryUpdater`] can | |
/// successfully call this method. |
/// Replace the account id that will be admin for all new tokens. This has no effect on | ||
/// tokens that were already deployed. |
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.
/// Replace the account id that will be admin for all new tokens. This has no effect on | |
/// tokens that were already deployed. | |
/// Replace the account id that will be admin for all new tokens. This has no effect on | |
/// tokens that were already deployed. | |
/// | |
/// Only accounts that are granted [`AclRole::TokenControllerUpdater`] can | |
/// successfully call this method. |
near_sdk::serde_json::json!({ | ||
"super_admin": self.token_super_admin, | ||
}) |
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.
super_admin
parameter of near-token-contract is Option<AccountId>
:
Maybe serde is implicitly doing the conversion? If not, shouldn't passing AccountId
instead of Option<AccountId>
cause a test failure?
Should we have tests to verify Acl is integrated correctly? For example like this: I would argue yes, since the Acl plugin is rather complex. Also these tests should catch things like using |
No description provided.