Для обратного вызова необходимо установить как pub и использовать макрос #[private], чтобы гарантировать, что он может быть вызван только самим контрактом:
В функции привилегий вызовите assert_owner(), чтобы ограничить выполнение только для владельца:
ржавчина
impl Контракт {
pub fn privileged_function(&mut self) {
self.assert_owner();
// Привилегированные операции
}
}
Таким образом, можно реализовать основное механизм белого списка, а также дополнительно расширить его для реализации сложного управления доступом для нескольких пользователей и нескольких белых списков.
Безопасность смарт-контрактов необходимо рассматривать с нескольких сторон, включая контроль времени вызова, многофакторные механизмы и т. д., которые будут подробно описаны в последующих статьях.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
9
Поделиться
комментарий
0/400
GasWaster
· 07-24 14:55
Снова изучаешь что-то глубокое?
Посмотреть ОригиналОтветить0
rugdoc.eth
· 07-24 12:22
Это слишком банально.
Посмотреть ОригиналОтветить0
GateUser-9ad11037
· 07-24 03:37
Стоит ли дополнить механизм черного списка~
Посмотреть ОригиналОтветить0
DefiPlaybook
· 07-23 10:17
Согласно комплексным данным, контроль посещений по-прежнему является одним из трех лучших уязвимостей контрактов.
Посмотреть ОригиналОтветить0
SeeYouInFourYears
· 07-21 20:27
rust вот так.
Посмотреть ОригиналОтветить0
OnchainDetective
· 07-21 20:27
Контроль доступа на самом деле бесполезен, давно пора проверить задние двери.
Безопасность смарт-контрактов Rust: подробное руководство по контролю доступа и управлению правами
Rust смарт-контракты养成日记(7)合约安全之访问控制
В этой статье будут рассмотрены два аспекта контроля доступа в смарт-контрактах на Rust:
1. Видимость функций смарт-контрактов
В Rust смарт-контрактах контроль видимости функций очень важен. Макрос #[near_bindgen] в NEAR SDK определяет следующие виды видимости:
Кроме того, можно определить внутренние методы через отдельный блок impl Contract:
ржавчина #[near_bindgen] impl Контракт { pub fn increment(&mut self) { self.internal_increment(); } }
impl Контракт { pub fn internal_increment(&mut self) { self.counter += 1; } }
Для обратного вызова необходимо установить как pub и использовать макрос #[private], чтобы гарантировать, что он может быть вызван только самим контрактом:
ржавчина #[near_bindgen] impl Контракт { #[private] pub fn resolve_transfer(&mut self) { // Логика обратного вызова } }
!
2. Контроль доступа к привилегированным функциям
Кроме видимости функций, необходимо установить механизм белого списка контроля доступа. Можно реализовать собственный Trait:
ржавчина pub trait Ownable { fn assert_owner(&self) { assert_eq!(env::p redecessor_account_id(), self.get_ owner()); } fn get_owner(&self) -> AccountId; fn set_owner(&mut Self, владелец: AccountId); }
В функции привилегий вызовите assert_owner(), чтобы ограничить выполнение только для владельца:
ржавчина impl Контракт { pub fn privileged_function(&mut self) { self.assert_owner(); // Привилегированные операции } }
Таким образом, можно реализовать основное механизм белого списка, а также дополнительно расширить его для реализации сложного управления доступом для нескольких пользователей и нескольких белых списков.
Безопасность смарт-контрактов необходимо рассматривать с нескольких сторон, включая контроль времени вызова, многофакторные механизмы и т. д., которые будут подробно описаны в последующих статьях.
!
!
!
!
!
!
!
!
!