Почему вынос логики авторизации важен для смарт-контрактов
...
Многие разработчики полагают, что авторизация должна находиться внутри смарт-контракта. Такой подход работает для простых проверок прав, но его становится сложно поддерживать по мере изменения требований комплаенса, лимитов на расходы или организационных условий.
Newton вводит концепцию оценки авторизации через отдельный слой политик до выполнения. Вместо того чтобы встраивать каждое правило авторизации в логику контракта, оценка политик отделяется от исполнения приложения. Это позволяет независимо управлять поведением авторизации, сохраняя бизнес-логику в фокусе ее непосредственного назначения.
Для бэкенд-разработчиков этот архитектурный паттерн аналогичен переносу авторизации из разрозненных обработчиков маршрутов в централизованный middleware. Во фреймворках вроде Node.js и Express аутентификация и авторизация обычно применяются до того, как запросы доходят до логики приложения. Разделение этих обязанностей улучшает поддерживаемость, облегчает обновление политик и способствует повторному использованию кода.
То же проектное правило можно применить и к инфраструктуре блокчейна. Политики, написанные на Rego, могут описывать правила авторизации независимо от логики приложения. Это уменьшает дублирование проверок прав в разных контрактах или сервисах и делает решения по авторизации проще для анализа и дальнейшего развития.
Для предприятий, AI-агентов и команд по инфраструктуре рассмотрение авторизации как отдельного архитектурного слоя может обеспечить более ясное управление и более прозрачное управление политиками — без переплетения операционных правил с реализацией контрактов.
Понимание авторизации как повторно используемой инфраструктуры может стать не менее важным, чем понимание самого исполнения.
...
Главный вывод: разделение авторизации и исполнения позволяет логике политик развиваться без необходимости снова и снова менять логику приложения.
#Newt @NewtonProtocol $NEWT
Официальная документация:
https://docs.newton.xyz/developers/overview/about
...
Многие разработчики полагают, что авторизация должна находиться внутри смарт-контракта. Такой подход работает для простых проверок прав, но его становится сложно поддерживать по мере изменения требований комплаенса, лимитов на расходы или организационных условий.
Newton вводит концепцию оценки авторизации через отдельный слой политик до выполнения. Вместо того чтобы встраивать каждое правило авторизации в логику контракта, оценка политик отделяется от исполнения приложения. Это позволяет независимо управлять поведением авторизации, сохраняя бизнес-логику в фокусе ее непосредственного назначения.
Для бэкенд-разработчиков этот архитектурный паттерн аналогичен переносу авторизации из разрозненных обработчиков маршрутов в централизованный middleware. Во фреймворках вроде Node.js и Express аутентификация и авторизация обычно применяются до того, как запросы доходят до логики приложения. Разделение этих обязанностей улучшает поддерживаемость, облегчает обновление политик и способствует повторному использованию кода.
То же проектное правило можно применить и к инфраструктуре блокчейна. Политики, написанные на Rego, могут описывать правила авторизации независимо от логики приложения. Это уменьшает дублирование проверок прав в разных контрактах или сервисах и делает решения по авторизации проще для анализа и дальнейшего развития.
Для предприятий, AI-агентов и команд по инфраструктуре рассмотрение авторизации как отдельного архитектурного слоя может обеспечить более ясное управление и более прозрачное управление политиками — без переплетения операционных правил с реализацией контрактов.
Понимание авторизации как повторно используемой инфраструктуры может стать не менее важным, чем понимание самого исполнения.
...
Главный вывод: разделение авторизации и исполнения позволяет логике политик развиваться без необходимости снова и снова менять логику приложения.
#Newt @NewtonProtocol $NEWT
Официальная документация:
https://docs.newton.xyz/developers/overview/about