как запустить net core приложение на линукс
ASP.NET Core: ваше первое приложение на Linux c использованием Visual Studio Code
Решил недавно написать небольшое ASP.Net MVC приложение после многолетнего перерыва и знающие люди на Хабре подсказали попробовать новый ASP.Net Core, тем более, что он работает в Линуксе из коробки без необходимости задействовать mono, и, судя по последним тестам, даже показывает неплохую производительность. За основу взял аналогичную статью для Mac, однако здесь в отличии от вдохновившей меня статьи хочу описать процесс пошагово в одном месте, для того, чтобы не пришлось лазить по перекрёстным ссылкам, пытаясь разобраться как установить непонятно для чего предназначенные приложения и пакеты. Такое подробное описание процесса возможно поможет многим избежать граблей, с которыми пришлось столкнуться мне. Несколько фраз и рисунков, в части одинаковой для любой платформы, с правками и корректировками взяты из статьи для Mac.
Приводимые здесь команды установки подходят для дистрибутивов Ubuntu 16.04/Mint 18.x, для остальных можно найти здесь.
Устанавливаем новейший на данный момент RC4 для совместимости с новейшим генератором проектов aspnet:
Установка Visual Studio Code
Устанавливается легко в пару кликов по этой ссылке.
Установка расширения C#
Запускаем Visual Studio Code, нажимаем Ctrl-P, вводим команду:
ext install csharp
В появившейся слева панели нажимаем «Установить» напротив соответствующего расширения, если это не произошло автоматически. Visual Studio Code можно пока закрыть.
Подготовка среды разработки и формирование шаблонов приложений
Устанавливаем новейший node.js с оригинального сайта (тот, что идёт с дистрибутивом не подходит), он нам нужен из-за менеджера пакетов npm, который идёт вместе с ним:
Для других дистрибутивов инструкция здесь.
Инициализация проекта
Для инициализации используется скаффолдер Yeoman — инициализатор проекта, включающий в себя развёртывание файловой структуры и генерацию шаблона проекта, т.е. исходного кода приложения. Включает в себя скаффолдер Yo, менеджер пакетов Bower и менеджер задач Grunt. При установке Yo вам будут установлены также Bower и Grunt. Здесь устанавливаем в любом терминале также новейший генератор aspnet, в котором возвращена система сборки msbuild вместо project.json:
Запуск генератора проекта
Your project is now created, you can use the following commands to get going
cd «WebApplicationBasic»
dotnet restore
dotnet build (optional, build will also happen with it’s run)
dotnet run
Восстановить и собрать можно, а вот запускать пока рано: нужно ещё кое что сделать.
Разработка приложений ASP.NET Core MVC на Linux с помощью Visual Studio Code
Теперь запустите Visual Studio Code. 
Выберите пункт Файл → Отрыть папку и выберите папку, в которой Вы создали шаблон приложения ASP.NET Core MVC с помощью yo.
Для тех, кто только приступает к использованию Visual Studio Code (или Code, для краткости), следует заметить, что данный продукт не только имеет удобный, простой и отзывчивый интерфейс, обеспечивающий быструю работу с файлами, но он также предоставляет инструменты для наиболее эффективного написания кода.
Code интегрируется с Git, если он установлен на вашем компьютере. При помощи Git viewlet можно создавать новые репозитории, подтверждать изменение кода, отправлять изменения.
Debug viewlet поддерживает интерактивную отладку приложений.
Запуск приложения при помощи Kestrel
Цель этой части
В этом разделе предполагается, что вы используете Ubuntu и используете средство командной строки APT для установки приложений.
Предварительные требования
В этой части предполагается, что вы знаете следующие процессы:
Если вы, по крайней мере, не знакомы с этими процессами, обратитесь к предыдущим частям перед продолжением.
Начните с запуска следующих команд:
Первая команда — wget это команда. В соответствии со своей страницей справки, wget это не интерактивный сетевой загрузщик. Он загружает файлы с http-серверов в каталоге. Он может работать в фоновом режиме, даже если пользователь не вошел в систему. Эта команда загружает файл wget Packages-microsoft-prod.deb с packages.microsoft.com серверов текущего каталога.
Если мы запускаем команду после запуска, мы должны увидеть, что пакет ls wget загружается в текущем каталоге.
Во второй команде dpkg — диспетчер пакетов для Debian и Ubuntu. Эта команда добавляет ключ подписи пакета Майкрософт в список доверенных ключей, а затем добавляет репозиторий пакета.
Так как мы скачали и добавили новый репозиторий пакетов, диспетчеру пакетов необходимо знать об этом. Поэтому мы должны обновить диспетчер пакетов с помощью sudo apt update команды.
Теперь диспетчер пакетов знает репозиторий Microsoft, и мы можем продолжить установку.
Различные версии этих приложений могут успешно работать бок о бок на одном компьютере.
Определение правильного имени пакета
Например, если вы хотите установить версию 5.0 ASP.NET Core, то продукт будет aspnetcore-runtime-5.0.
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Yet another tutorial: запускаем dotnet core приложение в docker на Linux
Предупреждение читателю: статья ориентирована на совсем новичков в docker/dotnet core и писалась большей частью, как напоминалка для себя. Вдохновлялся я первыми 3 частями Docker Get Started Guide и неким блог-постом на english. У кого хорошо с английским, можно читать сразу их и в общем-то будет сильно похоже. Если же после всего вышенаписанного вы еще не передумали продолжить чтение, то добро пожаловать под кат.
Пререквизиты
Итак нам понадобится собственно Linux (в моем случае это была Ubuntu 16.04 под VirtualBox на Windows 10), dotnet core, docker, а также docker compose, чтобы было удобнее поднимать сразу несколько контейнеров за раз.
Никаких особых проблем с установкой возникнуть не должно. По крайней мере, у меня таковых не возникло.
Формально можно писать хоть в блокноте и отлаживаться через логи или консольные сообщения, но т.к. я несколько избалован, то все-таки хотелось получить нормальную отладку и, желательно, еще и нормальный рефакторинг.
Из того, что может под Linux, для себя я попробовал Visual Studio Code и JetBrains Rider.
Visual Studio Code
Что могу сказать — оно работает. Отлаживаться можно, синтаксис подсвечивается, но уж очень все незатейлево — осталось впечатление, что это блокнот с возможностью отладки.
Rider
По сути Idea, скрещенная с решарпером — все просто и понятно, если работал до этого с любой IDE от JetBrains. До недавнего времени не работал debug под linux, но в последней EAP сборке его вернули. Вообщем для меня выбор в пользу Rider был однозначен. Спасибо JetBrains за их классные продукты.
Презреем в учебных целях кнопки Create Project различных IDE и cделаем все ручками через консоль.
1. Переходим в директорию нашего будущего проекта
2. Посмотрим ради интереса, какие шаблоны мы можем использовать
3. Создадим WebApi проект
4. Подтянем зависимости
5. Запустим наше приложение
6. Открываем http://localhost:5000/api/values и наслаждаемся работой C# кода на Linux
Готовим приложение к докеризации
Заходим в Program.cs и в настройке хоста добавляем
В итоге должно получится что-то типа
Соответственно, докеризовав dotnet core приложение с дефолтной настройкой прослушиваемых url можно потом довольно долго удивляться, почему проброс портов не работает, и перечитывать свой docker-файл в поисках ошибок.
Передача параметров в приложение
При запуске контейнера хотелось бы иметь возможность передавать приложению параметры.
Беглое гугление показало, что если обойтись без экзотики типа обращения изнутри контейнера к сервису конфигурации, то можно использовать передачу параметров через переменные окружения или подмену файла конфига.
Отлично, будем передавать через переменные окружения.
Собственно все — теперь можно инжектить параметры из переменных окружения куда угодно через DI.
При старте инстанса приложения будем генерировать новый Guid и засунем его в IoC-контейнер, чтобы раздавать страждущим. Нужно это, например, для анализа логов от нескольких параллельно работающих инстансов сервиса.
Все тоже достаточно тривильно — у ConfigurationBuilder вызываем:
После этих двух шагов public Startup(IHostingEnvironment env) будет выглядеть примерно так:
Он не показался мне хоть сколько-нибудь интуитивным. Глубоко я не копал, но тем не менее приведу ниже небольшой пример того, как прокинуть Id инстанса, который мы задаем при старте, и что-нибудь из переменных окружения(например переменную MyTestParam) в контроллер.
Первым делом надо создать класс настроек — имена полей должны совпадать с именами параметров конфигурации, которые мы хотим инжектить.
Далее идем в Startup.cs и вносим изменения в ConfigureServices(IServiceCollection services)
И последним шагом идем в наш подопытный и единственный созданный автоматом ValuesController и пишем инжекцию через конструктор
Собираем и запускаем docker-образ
1. Первым делом получим бинарники нашего приложения для публикации. Для этого открываем терминал, переходим в директорию проекта и вызываем:
Более подробно про команду можно почитать тут.
2. Собственно эту папочку мы и положим в наш docker-образ.
Для этого создадим в директории проекта Dockerfile и напишем туда примерно следующее:
3. После того, как Dockerfile написан, запускаем:
Где my-cool-service — имя образа, а 1.0 — тэг с указанием версии нашего приложения
4. Теперь проверим, что образ нашего сервиса попал в репозиторий:
5. И, наконец, запустим наш образ:
6. Открываем http://localhost:5000/api/values и наслаждаемся работой C# кода на Linux в docker
Посмотреть образы в локальном репозитории
Посмотреть запущенные контейнеры
Получить информацию о контейнере
Удалить все контейнеры и все образы
Немного docker-compose напоследок
docker-compose поднимает при старте между сервисами, описанными в docker-compose файле, локальную сеть и раздает hostname в соотвествии с названиями сервисов. Это позволяет таким сервисам удобно между собой общаться. Воспользуемся этим свойством и напишем простенький файл конфигурации для nginx
из директории с docker-compose.yml и получаем nginx, как reverse proxy для нашего приложения. При этом рекомендуется представить, что тут вместо nginx что-то действительно вам полезное и нужное. Например база данных при запуске тестов.
Надеюсь, что кому-нибудь эта статья поможет сэкономить немного времени на пути освоения docker и/или dotnet core.
Просьба к читателям: если вдруг среди вас у кого-нибудь есть опыт с dotnet core в продакшене на Linux (не обязательно в docker, хотя в docker особенно интересно) — поделитесь, пожалуйста, впечатлениями от использования в комментариях. Особенно будет интересно услышать про реальные проблемы и то, как их решали.
Часть 2.1 — создание и настройка ASP.NET Core приложений в Linux
В этой статье водится создание и настройка ASP.NET Core приложений в Linux.
Предварительные требования
Чтобы следовать упражнениям в этой части, необходимо установить SDK.NET Core. Чтобы установить SDK, при необходимости обратитесь к инструкциям по установке в части 1.
Цель этой части
.NET CLI
Эти тренинги часто dotnet используют команду. Эта команда является мощной и имеет две основные функции:
Вы будете использовать команду для создания первого проекта dotnet new ASP.NET Core в Linux. Эта команда получает тип проекта в качестве аргумента. Типы проектов объясняются в этом документе. Вы также можете отображать список типов, запуская dotnet new без параметра. Типы проектов, связанных с веб-сайтом, выделены желтым цветом на следующем скриншоте.
Эти правила применяются при dotnet new использовании:
Вы можете найти творческие имена для каталога и самого проекта. Однако имейте в виду, что Linux является чувствительным к делу. Для этого упражнения используйте более консервативное имя проекта и создайте его AspNetCoreDemo в firstwebapp каталоге.
Чтобы создать проект, запустите следующую команду:
Изучите выходные данные, чтобы увидеть каталог и имена проектов. На следующем скриншоте также перечислены содержимое каталога выходных данных. Вы должны быть знакомы со структурой каталога, если вы создали ASP.NET Core веб-приложение на Windows раньше.
Следующие элементы на этом скриншоте:
Рекомендуется не запускать приложение под домашним каталогом. Вы опубликуете его в другом каталоге позже, но перед публикацией его следует проверить. Чтобы остановить приложение, можно нажать кнопку Ctrl+C. Но пока держите его в работе и откройте новый сеанс терминала, используя предпочтительный метод для подключения к виртуальной машине Linux. В этом примере вы снова будете использовать PowerShell.
Тестирование веб-сайта из другого терминала
Вы можете использовать скручиваемость и wget для проверки веб-сайта. Обе команды делают вызов HTTP в целевую сторону, но ведут себя по-разному:
В команде также показано несколько дополнительных сведений, таких как перенаправление и сообщения об ошибках, которые wget вы можете получить. Поэтому его можно использовать как примитивную версию средства трассировки HTTP при необходимости.
При запуске curl http://localhost ничего не происходит. Это, скорее всего, означает, что http-ответ не существует. Затем можно выполнить проверку отображения дополнительных сведений при попытке wget http://localhost доступа к сайту.
Вот что происходит сейчас:
Редактирование файлов с помощью vi
Вы можете использовать текстовый редактор vi для дистрибутивов Linux для редактирования всех типов обычных текстовых файлов. Вы будете использовать его в этом обучении для перенастройки приложения.
Перед редактированием приложения необходимо закрыть приложение. Сначала закрой сеанс открытого терминала. Затем нажмите кнопку Ctrl+C, чтобы закрыть приложение.
Чтобы изменить файл Startup.cs, запустите следующую команду:
Эта команда запускает редактор vi и загружает файл. Ярлык
(tilde) относится к домашнему каталогу, в котором вы создали проект. То есть команда указывает на /home/ /firstwebapp/Startup.cs.
Нажмите клавишу I (Insert), чтобы включить режим редактирования. Теперь в нижней части командной строки должна быть вставка. Используйте клавиши стрелки для перемещения в файле. Комментарий как строк; так и строк, добавляя их в app.UseHsTs() app.UseHttpsRedirection() // начале, как показано на следующем скриншоте.
После нажатия ввода изменения должны быть сохранены. Вы можете проверить изменения, cat
Перезапустите приложение. Для этого измените текущий каталог на
/firstwebapp каталог и запустите dotnet снова. Затем откройте еще один сеанс терминала на сервере и запустите curl http://localhost:5000 команду снова. На этот раз команда должна вернуть содержимое HTML домашней страницы.
Теперь вы успешно запустили первое ASP.NET Core веб-приложение на Linux.
Развертывание приложения в каталоге /var
Основная цель этого упражнения — провести веб-приложение за обратным прокси-сервером, чтобы клиенты, подключившись, могли получить доступ к приложению с другого компьютера, используя только имя хост-сервера без номера порта. Это то, что вы ожидаете, что произойдет в реальном мире сценариев. Вы будете работать с Nginx позже для выполнения этой задачи. Но прежде чем это сделать, опубликуйте свое приложение в каталоге /var. Это потому, что рекомендуется не запускать приложение в домашнем каталоге пользователя.
Помните, что каталог /var используется для хранения контента и файлов журнала различными приложениями, такими как Apache и Nginx. Вы будете следовать этой практике здесь, опубликовав недавно созданное веб-приложение в /var.
Измените папку проекта и запустите dotnet publish для создания папки публикации. Скопируйте эту папку в каталог /var.
На скриншоте показано, что команда создала файлы публикации в dotnet publish папке
/firstwebapp/bin/Debug/net5.0/publish/. Затем для копирования всех файлов в папку /var/firstwebapp/folder была использована следующая команда:
Использование перед sudo командой копирования. Вы используете это, так как стандартные пользователи не имеют разрешения на написание каталога /var. Поэтому команду необходимо запустить в качестве суперусыла.
Чтобы запустить приложение из опубликованной папки, запустите следующую команду:
Если вы хотите, вы можете выполнить эти тесты с помощью тех же curl и wget команд. Это происходит потому, что приложение будет по-прежнему прослушивать в порту 5000 для http-запросов.
Срок службы процесса и последующие действия
Дальнейшие действия
Убедитесь, что веб-приложение запускается автоматически. Установите и настройте Nginx в качестве обратного прокси-сервера для маршрутизации http-запросов, которые сделаны для переноса 80 в приложение dotnet (чтобы клиенты могли подключаться без необходимости предоставлять номер порта).
Заявление об отказе от ответственности за сведения о продуктах сторонних производителей
В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.
Среда размещения ASP.NET Core в операционной системе Linux с Nginx
В этом руководстве описывается настройка готовой к работе среды ASP.NET Core на сервере Ubuntu 16.04. Эти инструкции могут подходить для более поздних версий Ubuntu, но они еще не были протестированы в этих версиях.
В этом руководстве рассматривается
Предварительные требования
Перезапустить приложения ASP.NET Core, размещенные на сервере, можно в любой момент после обновления общей платформы.
Публикация и копирование приложения
Если приложение запускается локально и не настроено для безопасного подключения (HTTPS), следует применять один из следующих подходов.
Если развертывание выполняется в рабочей среде, рабочий процесс непрерывной интеграции автоматически опубликует приложение и скопирует его ресурсы на сервер.
Проверьте работу приложения:
, чтобы убедиться, что приложение локально работает на платформе Linux.
Настройка обратного прокси-сервера
Обратный прокси-сервер — это стандартный вариант настройки для обслуживания динамических веб-приложений. Обратный прокси-сервер завершает HTTP-запрос и перенаправляет его в приложение ASP.NET Core.
Использование обратного прокси-сервера
Kestrel отлично подходит для предоставления динамического содержимого из ASP.NET Core. При этом компоненты для работы с веб-службами не настолько функциональны, как серверы типа IIS, Apache или Nginx. Обратный прокси-сервер может облегчить такую работу, как обслуживание статического содержимого, кэширование и сжатие запросов, а также терминирование HTTPS с HTTP-сервера. Обратный прокси-сервер можно разместить на отдельном компьютере или развернуть параллельно с HTTP-сервером.
В контексте данного руководства используется отдельный экземпляр Nginx. Он выполняется на том же сервере, что и HTTP-сервер. Настройки можно выбирать в зависимости от требований.
ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.
Установка Nginx
Если необходимы дополнительные модули Nginx, может потребоваться создание Nginx из источника.
Так как Nginx устанавливается впервые, запустите его напрямую, выполнив следующую команду.
Настройка Nginx
Если вы работаете с приложением SignalR или Blazor Server, дополнительные сведения см. в разделах о ASP.NET Core SignalR рабочее размещение и масштабирование и Размещение и развертывание ASP.NET Core Blazor Server соответственно.
Для непосредственного запуска приложений на сервере:
Если приложение выполняется на сервере, но не отвечает по Интернету, проверьте брандмауэр сервера и убедитесь, что порт 80 открыт. При использовании виртуальной машины Ubuntu Azure добавьте правило группы безопасности сети (NSG), которое разрешает входящий трафик через порт 80. Не нужно включать правило исходящего трафика на порте 80, так как исходящий трафик предоставляется автоматически при включении правила для входящего трафика.
Когда закончите тестировать приложение, завершите его работу с помощью клавиш CTRL + C в командной строке.
Мониторинг приложения
Создание файла службы
Создайте файл определения службы.
Далее представлен пример файла службы для нашего приложения:
Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли читать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:
Сохраните файл и включите службу.
Запустите службу и убедитесь, что она работает.
Просмотр журналов
Защита данных
Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.
Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:
Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.
Длинные поля заголовка запроса
Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 4 КБ или 8 КБ (в зависимости от платформы). Приложению могут потребоваться более длинные поля (например, приложениям, использующим Azure Active Directory). В этом случае требуется скорректировать параметры по умолчанию для прокси-сервера. Применяемые значения зависят от конкретного сценария. Дополнительные сведения см. в документации сервера.
Не увеличивайте значение буферов прокси-сервера по умолчанию, если это не требуется. Увеличение этих значений повышает риск переполнения буфера и атак типа «отказ в обслуживании» (DoS) со стороны злоумышленников.
Защита приложения
Включение AppArmor
Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor — это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.
Настройка брандмауэра
Неправильно настроенный брандмауэр предотвратит доступ ко всей системе. Если задать неправильный порт SSH, то при использовании SSH для подключения к системе произойдет ее блокировка. Порт по умолчанию — 22. Дополнительные сведения см. в вводной статье по ufw и в этом руководстве.
Установите ufw и настройте его для разрешения прохождения трафика через все необходимые порты.
Защита Nginx
Изменение имени ответа Nginx
Отредактируйте файл src/http/ngx_http_header_filter_module.c :
Настройка параметров
Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например ModSecurity.
Конфигурация HTTPS
Настройка приложения для безопасных (HTTPS) локальных подключений
Настройте приложение, чтобы оно использовало при разработке сертификат для команды dotnet run или среды разработки ( F5 или CTRL + F5 в Visual Studio Code), используя один из следующих подходов:
Настройка обратного прокси-сервера для безопасного подключения клиентов (HTTPS)
Конфигурация безопасности в этом разделе представляет собой общую конфигурацию, которая будет использоваться в качестве отправной точки для дальнейшей настройки. Мы не можем обеспечить поддержку инструментов, серверов и операционных систем сторонних производителей. Ответственность за использование конфигурации в этом разделе лежит на пользователе. Дополнительные сведения см. в следующих ресурсах:
Настройте сервер для прослушивания трафика HTTPS через порт 443, указав действительный сертификат, выпущенный доверенным центром сертификации (ЦС).
Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf.
В следующем примере не выполняется настройка сервера для перенаправления небезопасных запросов. Рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS. Для получения дополнительной информации см. Принудительное применение HTTPS в ASP.NET Core.
Для сред разработки, в которых безопасное перенаправление обрабатывается конфигурацией сервера, а не ПО промежуточного слоя перенаправления HTTPS, рекомендуется использовать временные перенаправления (302), а не постоянные перенаправления (301). Кэширование ссылок может привести к нестабильной работе в средах разработки.
При добавлении заголовка Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS. Рекомендации по настройке заголовка Strict-Transport-Security см. в разделе Принудительное применение HTTPS в ASP.NET Core.
Если протокол HTTPS будет отключен в будущем, используйте один из следующих подходов.
Добавьте файл конфигурации /etc/nginx/proxy.conf:
Замените содержимое файла конфигурации /etc/nginx/nginx.conf следующим файлом. В этом примере показаны разделы http и server одного и того же файла конфигурации.
Приложениям Blazor WebAssembly требуется большее значение параметра burst с учетом большего количества запросов, выполняемых приложением. Для получения дополнительной информации см. Размещение и развертывание ASP.NET Core Blazor WebAssembly.
В предыдущем примере ассоциация протокола OCSP отключена. Если он включен, убедитесь, что сертификат поддерживает эту возможность. Дополнительные сведения и рекомендации по включению протокола OCSP см. в описании следующих свойств в статье Модуль Ngx_http_ssl_module (документация по Nginx):
Защита Nginx от кликджекинга
Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.
Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.
Измените файл nginx.conf.
Добавьте строку: add_header X-Frame-Options «SAMEORIGIN»;
Сканирование типа MIME
Измените файл nginx.conf.
Добавьте строку: add_header X-Content-Type-Options «nosniff»;