Я размышлял о том, что на самом деле означает добавление слоя авторизации к контракту, который уже находится в работе.
Руководство по интеграции Newton показывает, как существующий upgradeable-контракт может наследовать "NewtonPolicyClient" через прокси-апгрейд, сохраняя при этом свою существующую структуру хранилища и бизнес-логику. После апгрейда функция, контролируемая владельцем, может инициализировать клиент Newton, а выбранные сценарии выполнения могут начать требовать корректные аттестации, прежде чем они продолжат.
Сначала это выглядело как чистая модульность.
Приложение не нужно перестраивать вокруг Ньютон с самого начала. Принудительное применение политики можно добавить позже — это важно для контрактов, которые уже держат состояние и не могут просто быть заново развернуты с нуля.
Но руководство задает условия миграции необычно конкретно. 
Новые переменные хранения должны быть добавлены в существующую раскладку хранения, а не вставляться в нее. В примере Ньютон также вводится специальный флаг "_newtonPolicyClientInitialized", чтобы функция инициализации после апгрейда вызывалась не более одного раза. Руководство рекомендует тщательно протестировать апгрейд на форке и рассмотреть таймлок или мультисиг для вызова инициализации.
Что бросилось в глаза — это было не только то, что можно дооснастить проверки политики.
Насколько сильно безопасность концентрируется вокруг процесса апгрейда и инициализации.
Перед инициализацией обновленный контракт может содержать логику авторизации Ньютон, но его policy client еще не подключен к предполагаемому TaskManager или не назначен предполагаемому владельцу policy-client. Ньютон отмечает, что использование неверного адреса TaskManager может привести к тому, что проверка аттестации не пройдет, тогда как владелец policy-client контролирует важные функции управления политикой.
Вот почему важен одноразовый флаг.
Это предотвращает повторное выполнение функции инициализации примера, но при этом делает особенно чувствительным первый успешный вызов. Флаг может остановить повторную инициализацию; он не может подтвердить, что адреса, переданные во время исходного вызова, были корректными.
При этом инициализация не замораживает навсегда каждую часть конфигурации Ньютон. Владелец policy-client позже может установить или обновить конфигурацию политики, изменить адрес контракта политики и передать владение policy-client через функции, доступные в "NewtonPolicyClient".
Правило хранения несет другой вид риска.
Ньютон можно добавить без замены всей бизнес-логики приложения, но при этом прокси-апгрейд должен все равно сохранить предыдущую раскладку (layout) хранения. Вставьте новые переменные не в том месте — и код авторизации может выглядеть корректно встроенным, в то время как под ним будет повреждено несвязанное состояние контракта.
Есть еще одна граница, которая важна.
Добавление новой функции, защищенной Ньютоном, не обеспечивает автоматически безопасность более старой функции, которая по-прежнему раскрывает то же действие без проверки аттестации. Соответствующий путь выполнения должен на самом деле требовать "_validateAttestation" или "_validateAttestationDirect" до того, как выполнится защищенная бизнес-логика. Ньютон прямо предупреждает, что валидация должна происходить до выполнения.
Сила дизайна по-прежнему реальна.
Разделение "NewtonPolicyClient" и исходной логики приложения делает постепенное внедрение возможным. Существующую бизнес-логику в основном можно оставить на месте, а выбранные пути выполнения — изменить или расширить так, чтобы требовалось одобрение политики.
Это менее разрушительно, чем заставлять каждое приложение переходить в полностью новую архитектуру контрактов.
Часть, которую я еще не прояснил, — снижает ли такая модульность риск апгрейда или же концентрирует внимание на меньшем числе особенно чувствительных шагов.
Ньютон делает проще внедрение авторизации в существующий апгрейдируемый контракт.
Но означает ли это также, что прокси-апгрейд, миграция хранения и первый вызов инициализации превращаются в самые важные решения по авторизации во всей интеграции?
#Newt #NEWT @NewtonProtocol $TLM $M
