Для функцій зворотного виклику необхідно встановити публічний доступ та використовувати макрос #[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
Загальні дані показують, що контроль доступу залишається в топ-3 вразливостей контрактів.
Переглянути оригіналвідповісти на0
SeeYouInFourYears
· 07-21 20:27
rust так виглядає
Переглянути оригіналвідповісти на0
OnchainDetective
· 07-21 20:27
Контроль доступу є формальним, давно слід перевірити задні двері.
Безпека смартконтрактів на Rust: детальний розгляд контролю доступу та управління правами
Rust смартконтракти養成日記(7)合約安全之訪問控制
Ця стаття представить контроль доступу в смартконтрактах Rust з двох точок зору:
1. Видимість функцій контракту
У Rust смартконтрактах контроль видимості функцій є дуже важливим. У NEAR SDK #[near_bindgen] макрос визначає такі видимі властивості:
Крім того, можна визначити внутрішні методи через окремий блок impl Contract:
іржа #[near_bindgen] impl Контракт { pub fn increment(&mut self) { self.internal_increment(); } }
impl Контракт { pub fn internal_increment(&mut self) { self.counter += 1; } }
Для функцій зворотного виклику необхідно встановити публічний доступ та використовувати макрос #[private], щоб забезпечити виклик лише з самого контракту:
іржа #[near_bindgen] impl Контракт { #[private] pub fn resolve_transfer(&mut self) { // Логіка зворотного виклику } }
!
2. Контроль доступу до функцій привілейованих
Крім видимості функцій, потрібно також встановити механізм контрольного списку доступу. Можна реалізувати власний Trait:
іржа паб риса Власна { 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(); // Привілейовані операції } }
Це дозволить реалізувати базовий механізм білого списку, а також подальше розширення для реалізації доступу з кількома користувачами, кількома білими списками та іншим складним контролем доступу.
Безпека смартконтрактів потребує розгляду з кількох аспектів, включаючи контроль за часом виклику, багатопідписну механіку тощо, що буде детально розглянуте в наступних статтях.
!
!
!
!
!
!
!
!
!