Проверка доступных разрешений в Deno

Сразу после встроенной поддержки TypeScript, вероятно, вторая по популярности новая функция Deno - это добавленный уровень безопасности. Как вы, вероятно, уже знаете, вам нужно указать, какие разрешения вам необходимы для предоставления кода для его выполнения, в противном случае он потерпит неудачу.

Если задуматься, неудача обычно не лучший выход для части программного обеспечения, это определенно не лучший UX, который мы можем предоставить нашим пользователям, и это не то, как мы хотим писать программное обеспечение, если мы хотим, чтобы люди его приняли. Я имею в виду, можете ли вы представить, как ваша ОС выйдет из строя и заставит вас перезагружать компьютер каждый раз, когда что-то неожиданно происходит? Что ж, вы меня туда доставили, вероятно, это был шаблон UX Microsoft в течение долгого времени, но это уже не так, хорошо ?!

Я хочу сказать, что, учитывая это новое поведение, которое мы не сейчас должны применять, благодаря Deno, я вижу потенциально новый шаблон для серверной части: Проверка доступных разрешений или, как я люблю называть это: CAP.

Суть CAP в том, что если вы продолжаете работать так, как до сих пор, над своими внутренними проектами, в тот момент, когда кто-то попытается выполнить ваш код без достаточных разрешений, все приложение рухнет. За исключением HRTime (который ограничивает точность измерения), Deno не снижает изящно тот факт, что у вас недостаточно прав для доступа к одной из других функций, и напрямую выдает исключения типа PermissionDenied .

Что, если бы вместо того, чтобы просто дать сбой, ваш код мог бы проверить, действительно ли вам предоставлены разрешения, прежде чем пытаться выполнить код, который их требует? Конечно, могут быть случаи, когда вы ничего не сможете сделать без них, и вам придется остановить выполнение, но в других случаях вы можете изящно деградировать логику до чего-то, способного по-прежнему функционировать. Например: возможно, вам не были предоставлены права на запись, поэтому ваш модуль регистратора просто выводит все в STDOUT. Возможно, доступ к ENV не был предоставлен, но вы можете попробовать прочитать эти значения из конфигурации по умолчанию.

В настоящее время код, необходимый для работы этого шаблона, является экспериментальным и потенциально может измениться в будущих обновлениях, поэтому вам придется использовать флаг --unstable для его выполнения. Я, конечно, имею в виду API внутри Deno.permissions.

Совет. Используйте Bit (Github) для совместного использования, документирования и управления повторно используемыми компонентами из разных проектов. Это отличный способ увеличить повторное использование кода, ускорить разработку и создавать масштабируемые приложения.

Bit поддерживает Vanilla JS, TypeScript, React, Angular, Vue и многие другие.

Запрос разрешений

Самый простой из трех методов, доступных в настоящее время по пути Deno.permissions, - это query. Его также можно использовать, чтобы убедиться, что не только вам было предоставлено определенное разрешение, но и что у вас есть доступ к определенному месту (например, к белым спискам). В следующем фрагменте кода, например, показано, как проверить, есть ли у вас доступ для чтения к одной конкретной папке.

Если вместо этого вы не хотите ограничиваться проверкой определенного разрешения, а вместо этого запрашиваете его, потому что, в конце концов, оно вам нужно, у вас также есть метод request.

Запрос разрешений

Этот метод работает аналогично query, но вместо того, чтобы разрешить текущее состояние разрешения, он сначала предложит пользователю предоставить ответ, а затем он разрешит все, что пользователь выбрал.

Приведенный выше фрагмент показывает, что на самом деле код для запроса и запроса разрешения точно такой же (за вычетом имени метода, конечно), хотя результат немного отличается, посмотрите следующее изображение, чтобы увидеть, что вы получите от использования метода запроса.

Вы даже можете добавить дополнительный параметр к очень, если определенное место или ресурс в этой группе доступны. Помните, что в настоящее время белый список поддерживает следующие разрешения: чтение, запись и подключение к сети.

Для первых двух вы можете использовать свойство path объекта, чтобы запрашивать разрешения на определенный путь, будь то файл или папка. А для сетевого ресурса вы можете использовать свойство url.

Во всех трех случаях сообщение, показываемое пользователю, будет обновлено, чтобы также указать путь или URL ресурса, к которому вы хотите получить доступ:

Примечание. Хотя флаг --allow-net не требует указывать протокольную часть URL-адреса при добавлении доменов в белый список, здесь, чтобы запросить доступ к ним, вам нужно будет указать полный URL-адрес, в противном случае , вы получите сообщение об ошибке.

Последняя строка из приведенного выше кода показывает, что на самом деле вы можете запросить доступ к нескольким ресурсам в любой момент времени, если они относятся к одному типу. В следующем примере показано, что впоследствии вы можете без проблем запрашивать эти разрешения по отдельности.

Все, что вы ответите в первом вопросе, позже будет возвращено для обоих ресурсов.

Наконец, последнее, что позволяет вам сделать API разрешений, - это отозвать ваш собственный доступ к определенному ресурсу.

Отзыв разрешений

Для этого метода (метод revoke) тот же объект может быть предоставлен в качестве аргумента, как и в случае с двумя другими методами, и результатом является удаление доступа к ресурсу, к которому вы могли бы получить доступ через флаги интерфейса командной строки. .

Хотя это немного противоречиво, оно может быть полезно, если вы создаете некоторый код автоматизации, который должен реагировать на изменения конфигурации, или, возможно, какую-то систему управления процессами, которая должна предоставлять и отзывать разрешения для различных служб. Или, возможно, перезаписать все разрешения, предоставленные сценарию из командной строки.

Примечание. Эта последняя часть важна, поскольку и request, и revoke метод переопределят все флаги, использованные во время выполнения.

Поэтому, если вы пытаетесь убедиться, что вашим скриптам (или чьим-то еще) не предоставлены дополнительные разрешения для ресурсов, которых у них не должно быть, этот метод может оказаться очень кстати.

Не имеет значения, используете ли вы флаг --allow-env при вызове скрипта сверху, вы не получите доступа к этой переменной среды.

Заключение

Безопасность, безусловно, является большой проблемой при создании программного обеспечения, которое будут использовать другие, чтобы обеспечить им этот дополнительный уровень душевного спокойствия, и, если вы находитесь по ту сторону забора, используя программное обеспечение, созданное другими.

И хотя механизм флагов безопасности может показаться немного неуклюжим или неудобным для внутреннего разработчика, которому никогда не приходилось об этом беспокоиться раньше, они предоставляют проверенный и проверенный подход, который в сочетании с CAP (о да, я собираюсь мое имя здесь) это дает довольно хороший пользовательский опыт.

Эта статья является частью книги о Deno, которую я сейчас пишу, поэтому, если вы хотите узнать больше о Deno и о том, как работает уровень безопасности, вы можете прочитать больше об этом проекте здесь.

Наконец, позвольте мне спросить вас: пробовали ли вы раньше эти методы? Вы придумали другой шаблон или позволяете сценариям давать сбой? Оставьте комментарий ниже!

Учить больше