Add building blocks for Acl plugin#5
Conversation
Avoid confusion of numbers in role names with indexes of variants.
To be implemented in follow-up PR.
| #[private] | ||
| fn acl_grant_role_unchecked(&mut self, role: String, account_id: ::near_sdk::AccountId) -> bool { | ||
| let role = <#role_type>::try_from(role.as_str()).expect(#ERR_PARSE_ROLE); | ||
| self.#acl_field.grant_role_unchecked(role, &account_id) |
There was a problem hiding this comment.
Can you remind me what was the reason to have acl as an injected field versus having a function that builds this object dynamically? For example:
| self.#acl_field.grant_role_unchecked(role, &account_id) | |
| self.__acl_object().grant_role_unchecked(role, &account_id) |
There was a problem hiding this comment.
The part I don't like about injecting the code without letting developers know is that they might struggle to upgrade their contracts and serialize/deserialize the state later.
There was a problem hiding this comment.
If the field is not injected we (or the developers) have to manually (de)serialize and read/write the object from/to storage. Probably using storage_read and storage_write. We discussed offline to inject the field, to avoid the steps mentioned above.
I have not yet checked if it's feasible, but another approach might be:
- Ask the developer to have a field
__acl: (). The type this field should ultimately have is defined only inside the attribute macro. So I think developers can't write__acl: AclTypein their contract. - Inside the macro, we change the type of this field (instead of injecting a new field).
Probably it wouldn't be a huge win, but makes it more explicit.
There was a problem hiding this comment.
near-floating-state fits nicely here! Let's stay with injection for now to finalize this PR soon? Then once near-floating-state is on crates.io we can introduce it for Acl in a follow-up PR.
3 participants
Acl: Access control lists
This PR adds building blocks for an Acl plugin, inspired by OpenZeppelin Access Control.
There is a contract in
near-plugins/tests/contracts/access_controllablewhich shows how to use the plugin. In integration testnear-plugins/tests/access_controllable.rsthe contract is compiled, deployed and transactions are sent to it (all viaworkspaces-rs).Note: If this doesn't compile, #6 should fix it.
Overview
AccessControlRolefor that enum. It defines a bitflag type that encodes permissions and implements helpers for the conversion between roles (i.e. variants of the enum) and bitflags.#[access_control]which injects the structure that manages permissions into the contract.self.acl_has_role(role, account_id))#[access_control_any(roles(Role::LevelA, Role::LevelB)])Roadmap
This PR adds the basics for Acl and the contract and integration test mentioned above ensure that everything is wired together correctly. Upcoming PRs will add functionality to make this plugin feature equivalent to OpenZeppelin Access Control.
The target branch is
acl(instead of master) since there will be more PRs on top of this.