Cet article présentera le contrôle des permissions dans les smart contracts Rust sous deux aspects :
La visibilité des méthodes de contrat
Contrôle d'accès des fonctions privilégiées
1. Visibilité des fonctions de contrat
Dans les smart contracts Rust, le contrôle de la visibilité des fonctions est très important. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où une fonction de transfert clé a été par erreur définie comme publique, mettant ainsi en danger les actifs des utilisateurs.
Dans les smart contracts en Rust, il existe plusieurs types de visibilité des fonctions :
pub fn : fonction publique, peut être appelée depuis l'extérieur du contrat
fn: uniquement appelable par les contrats internes
pub(crate) fn: uniquement callable à l'intérieur de crate
Il est également possible d'implémenter des fonctions internes en définissant des méthodes dans des blocs impl non annotés par #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques, mais il faut s'assurer qu'elles ne peuvent être appelées que par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour réaliser cela.
Il est important de noter que, par défaut, tout est privé dans Rust, ce qui est différent de la version publique par défaut de certaines anciennes versions de Solidity.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est également nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès sur le plan sémantique.
Tout comme le modificateur onlyOwner dans Solidity, nous pouvons implémenter un Trait personnalisé en Rust:
De cette manière, il est possible de réaliser que seul le propriétaire peut appeler certaines fonctions de privilège.
Sur cette base, il est possible de définir des listes blanches plus complexes pour réaliser un contrôle d'accès par groupe plus fin.
D'autres méthodes de contrôle d'accès telles que le contrôle du moment de l'appel et le mécanisme à plusieurs signatures seront présentées dans les articles suivants.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
10 J'aime
Récompense
10
5
Reposter
Partager
Commentaire
0/400
Rugman_Walking
· Il y a 16h
Encore un vieux piège de Bancor, j'ai failli perdre jusqu'à mes pantalons.
Voir l'originalRépondre0
TokenToaster
· 08-07 12:36
bancor est vraiment un exemple stupide
Voir l'originalRépondre0
MevTears
· 08-06 06:28
J'ai vu celui de Bancor, c'est vraiment nul.
Voir l'originalRépondre0
OnlyOnMainnet
· 08-06 06:26
Ouf, les affaires de Bancor me font encore peur jusqu'à présent.
Voir l'originalRépondre0
0xLuckbox
· 08-06 06:18
Pourquoi y a-t-il toujours des gens qui se trompent dans les paramètres de permission ?
Contrôle d'accès dans les smart contracts Rust : visibilité des fonctions de contrat et accès privilégié
Contrôle d'accès dans les smart contracts Rust
Cet article présentera le contrôle des permissions dans les smart contracts Rust sous deux aspects :
1. Visibilité des fonctions de contrat
Dans les smart contracts Rust, le contrôle de la visibilité des fonctions est très important. Prenons l'exemple de l'incident de sécurité de l'échange Bancor Network en juin 2020, où une fonction de transfert clé a été par erreur définie comme publique, mettant ainsi en danger les actifs des utilisateurs.
Dans les smart contracts en Rust, il existe plusieurs types de visibilité des fonctions :
Il est également possible d'implémenter des fonctions internes en définissant des méthodes dans des blocs impl non annotés par #[near_bindgen].
Pour les fonctions de rappel, elles doivent être définies comme publiques, mais il faut s'assurer qu'elles ne peuvent être appelées que par le contrat lui-même. Vous pouvez utiliser le macro #[private] pour réaliser cela.
Il est important de noter que, par défaut, tout est privé dans Rust, ce qui est différent de la version publique par défaut de certaines anciennes versions de Solidity.
2. Contrôle d'accès des fonctions privilégiées
En plus de la visibilité des fonctions, il est également nécessaire d'établir un mécanisme complet de liste blanche de contrôle d'accès sur le plan sémantique.
Tout comme le modificateur onlyOwner dans Solidity, nous pouvons implémenter un Trait personnalisé en Rust:
rouille pub trait Ownable { fn assert_owner(&self) { assert_eq!(env::predecessor_account_id(), self.get_owner()); } AccountId; fn set_owner(&mut self, owner: AccountId); }
De cette manière, il est possible de réaliser que seul le propriétaire peut appeler certaines fonctions de privilège.
Sur cette base, il est possible de définir des listes blanches plus complexes pour réaliser un contrôle d'accès par groupe plus fin.
D'autres méthodes de contrôle d'accès telles que le contrôle du moment de l'appel et le mécanisme à plusieurs signatures seront présentées dans les articles suivants.