как развернуть asp net core на сервере linux
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
Развертывание веб-приложения ASP.NET на виртуальной машине Linux в Azure
В этой статье представлено пошаговое руководство по развертыванию веб-приложений ASP.NET (на примере проекта на фреймворке DotVVM) на виртуальной машине Ubuntu Server 20.04 в Microsoft Azure.
Вот основные шаги, которые мы разберем:
создание виртуальной машины в Azure на основе дистрибутива Linux;
публикация веб-приложения ASP.NET в Visual Studio 2019;
размещение веб-приложения на виртуальной машине;
подключение базы данных в виртуальной машине.
Создание виртуальной машины в Azure на основе дистрибутива Linux
Для начала нам понадобится подписка на Azure. Если у вас ее нет, учетную запись можно бесплатно создать здесь.
Перейдите на портал Azure, найдите вкладку Virtual Machines (Виртуальные машины) и создайте новую машину. В этом процессе есть несколько важных моментов, которые мы подробно рассмотрим ниже.
Общие настройки
Для начала нужно указать подписку, группу ресурсов и параметры нового экземпляра. На этом этапе мы выберем операционную систему (в нашем случае — Ubuntu Server 20.04) и размер виртуальной машины.
Теперь нужно ввести данные учетной записи администратора — имя пользователя и пароль. Это очень важно, чтобы в дальнейшем получить доступ к нашей машине. Здесь нам предлагают выбрать из двух опций — создать открытый ключ SSH (SSH public key) или придумать пароль. Выбрав вариант с паролем, увидим такую форму:
Осталось определить правила для входящих портов. В данном случае нам понадобится порт 80 для HTTP-соединений, который позволит получить доступ к сайту в браузере. Другой порт — SSH (22) — обеспечит удаленный доступ к виртуальной машине.
Дальнейшие настройки
Теперь, когда мы указали основную информацию, можно еще раз проверить все параметры и создать машину. В другом сценарии мы также могли бы указать тип жесткого диска (SSD или HDD), конфигурацию сети, балансировку нагрузки, параметры управления самой машиной и расширениями.
Закончив с настройками, запустите процесс создания машины. Это займет несколько минут.
Когда все готово, перейдем в главный раздел Azure и получим открытый IP-адрес, назначенный нашей виртуальной машине.
В его настройках мы можем выбрать опцию Static (статический) — это значит, что IP-адрес не будет меняться во время перезагрузки виртуальной машины. Мы также можем указать DNS для нашего открытого IP-адреса.
Теперь, когда у нас есть виртуальная машина с Ubuntu Server 20.04, размещенная в Azure, мы можем установить с ней удаленное соединение по протоколу SSH (Secure Shell) через консоль управления.
Запустим следующую команду с именем пользователя (которое мы указали при создании ВМ в Azure), IP-адресом или DNS:
Здесь нужно ввести учетные данные для доступа к машине:
Установка Apache
Чтобы сделать наше приложение доступным в интернете, нам понадобятся IIS, Nginx или Apache в качестве обратного прокси-сервера, который будет принимать HTTP-запросы и перенаправлять их на Kestrel (веб-сервер, который по умолчанию включен в шаблоны проектов ASP.NET).
Для установки Apache мы должны ввести следующие команды:
Учитывая, что порт 80 нашей виртуальной машины открыт, мы можем скопировать ее открытый IP-адрес или DNS и запустить их в браузере. Если Apache установлен правильно, мы увидим его стартовую страницу:
Теперь нам понадобятся модули Apache mod_proxy для выполнения функций обратного прокси-сервера:
Публикация веб-приложения ASP.NET в Visual Studio 2019
Для примера возьмем веб-приложение, созданное на фреймворке DotVVM, в основе которого лежит шаблон MVVM из ASP.NET 5.
В открывшемся диалоговом окне создадим новый профиль публикации типа Folder (Папка) и укажем путь к папке для развертывания файлов:
Теперь опубликуем решение из созданного профиля:
В результате наши файлы будут развернуты в указанной папке:
Мы используем их для выполнения следующей операции на виртуальной машине.
Размещение веб-приложения на виртуальной машине
Настройка сервера Apache
Обратите внимание: вы можете задать нужное вам имя файла.
Содержимое нашего файла DotNetApp.conf будет таким:
Помимо этого, в файле конфигурации DotNetApp.conf мы указали, что к нашему приложению можно получить доступ через порт 80. В таком случае мы можем сменить порт, но важно при этом не забыть сделать то же самое в настройках нашей виртуальной машины в Azure.
Копирование файлов приложения на виртуальную машину
Теперь нужно изменить настройки веб-приложения так, чтобы оно стало доступным через порт 80. Для этого мы копируем файлы, развернутые в Visual Studio 2019, на виртуальную машину. Это можно сделать из каталога /var/.
Теперь выполним передачу файлов. В Windows для этого используется программа WinSCP, которая позволяет подключаться к виртуальным машинам.
Завершив установку и инициализацию WinSCP, создадим на виртуальной машине в Azure новый сеанс с нашими учетными данными.
В папке пользователя по умолчанию создадим новую папку, например App, и скопируем в нее файлы приложения:
Теперь наше веб-приложение полностью размещено на виртуальной машине.
Создание службы для запуска приложения и контроля его работы
Чтобы создать файл службы, который позволит запускать наше веб-приложение, откроем редактор Nano:
В содержимом файла укажем рабочий каталог и файл для запуска веб-приложения.
Запустим созданную службу.
Теперь перезапустим сервер Apache и убедимся, что наше приложение работает через порт 80.
Завершив размещение и настройку, мы сможем получить доступ к веб-приложению через браузер, используя назначенный IP-адрес или DNS-имя. Как видите, наше приложение ASP.NET, созданное на фреймворке DotVVM, отлично работает на виртуальной машине Linux в Azure.
Подключение базы данных в виртуальной машине
Итак, мы успешно завершили установку приложения. Но это еще не все. Большинство современных веб-проектов (если не все) связаны с базами данных. В этом примере мы разберем, как установить на виртуальную машину базу данных PostgreSQL и связать ее с нашим проектом на DotVVM в ASP.NET 5.
Для установки PostgreSQL введем следующие команды:
Далее в настройках виртуальной машины в Azure нужно открыть порт 5432 для удаленного доступа к PostgreSQL.
Теперь на Ubuntu Server мы должны внести изменения в файл pg_hba.conf, чтобы разрешить удаленное подключение к PostgreSQL.
Пропишем в секции IPv4 local connections файла pg_hba.conf следующую строку:
Еще один файл, в который мы должны внести изменения, называется postgresql.conf. Эта конфигурация определяет, какие IP-адреса могут удаленно подключаться к PostgreSQL.
В секции Connections and Authentication удалим символ # и оставим следующую строку:
Теперь перезапустим службу базы данных.
Установив эти настройки, мы можем создать пользователя для доступа к базе данных, как в этом примере:
Осталось только изменить соответствующие настройки нашей базы данных. Сделав это, мы сможем удаленно подключаться к ней от имени пользователя, которого мы только что создали.
В завершение мы должны установить в нашем веб-приложении новое подключение к базе данных.
Чтобы эти изменения вступили в силу, нужно заменить файлы в каталоге /var/DotNetApp на другие, с новой конфигурацией, и перезапустить соответствующие службы (Kestrel и Apache).
Спасибо за внимание
Спасибо, что прочитали эту статью. Надеюсь, она показалась вам интересной и полезной. Если у вас появились вопросы или идеи, которыми хочется поделиться, я всегда открыт для общения, участия в совместных проектах и обмена опытом.
Всех желающих приглашаем на открытый урок «Как устроена сериализация». На занятии мы:
— Рассмотрим, что такое сериализации, и какие бывают форматы: плюсы и минусы каждого;
— Поработаем с XML, JSON и бинарным представлением данных языка.
>> РЕГИСТРАЦИЯ
Разворачиваем и демонизируем ASP.NET Core приложение под Linux в виде фонового сервиса
Подготовка окружения
Для начала, добавим dotnet-репозиторий:
На выходе получаем примерно следующее:
Теперь обновим индекс наших пакетов:
Далее, мы можем просто установить dotnet-пакет при помощи apt-get:
Теперь можем смело приступать к созданию приложения
Создание приложения
При помощи команды dotnet new мы можем создать шаблон для нашего приложения, подобно шаблонам из Visual Studio. Подробная документация к команде.
На текущий момент (07.2017), команда dotnet new поддерживает следующие шаблоны:
Мы создадим веб-приложение ASP.NET Core:
На выходе консоль выдаст нам следующее сообщение:
Теперь можем собрать приложение:
Запустим приложение с помощью:
Консоль говорит нам, что приложение запустилось по адресу localhost:5000/. Проверим:
Желающих подробнее узнать, как работает web-сервер отсылаю к официальному источнику.
Теперь убьём процесс нажав Ctrl + C и опубликуем приложение командой dotnet publish. Эта команда упаковывает приложение и все его зависимости для дальнейшего развёртывания (желающим интимных подробностей сюда).
В случае проблем с правами доступа Вам поможет команда sudo chmod и эта страница документации.
Развертывание на сервере.
Если мы хотим развернуть наше приложение под linux-сервером, необходимо настроить прокси и демонизировать процесс запуска приложения. Для проксирования мы будем использовать nginx, для демонизации процесса systemd. Краткое описание утилиты
Как следует из документации выше, с asp.net core в коробке идет kestrel — веб-сервер для asp.net приложений. Зачем нам тогда нужен прокси-сервер? Ответ даётся на официальной странице Microsoft:
Если вы выставляете ваше приложение в интернет, Вы должны использовать IIS, Nginx или Apache как обратный прокси-сервер.
Обратный прокси-сервер получает HTTP запросы из сети и направляет их в Kestrel после первоначальной обработки, как показано на след диаграмме:
Главная причина, по которой следует использовать обратный прокси сервер — безопасность. Kestrel относительно нов и ещё не имеет полного комплекта защиты от атак.
Ещё одна причина, по которой следует использовать обратный прокси-сервер — наличие на сервере нескольких приложений, использующих один порт. Kestrel не поддерживает разделение одного порта между несколькими приложениями.
Так же, использование обратного прокси-сервера может облегчить распределение нагрузки и поддержку SSL.
Как говорилось выше, в качестве прокси-сервера мы будем использовать nginx.
Т.к. в качестве прокси-сервера у нас используется не IIS, следует добавить следующие строки в метод Configure файла Startap.cs.
Здесь мы включаем поддержку ForwardedHeaders мидлвера из пакета. Microsoft.AspNetCore.HttpOverrides, который будет вставлять в Http-запрос заголовки X-Forwarded-For и X-Forwarded-Proto, использующиеся для определения исходного IP адреса клиента и передачи его прокси-серверу. Определение мидлверов и практическое использование так же будет рассмотрено в дальнейших частях этого гайда.
Если у Вас nginx не установлен, выполните следующую команду.
и запустите его командой:
Далее, нам необходимо сконфигурировать nginx для проксирования http-запросов.
Создадим файл /etc/nginx/sites-available/aspnetcore.conf. Папка sites-avalible укахывает nginx-у, какие веб-сайты доступны на текущем сервере для обработки. Добавим в него следующие строки:
Создадим символическую ссылку на aspnetcore.conf в папку sites-enabled, в которой отражаются запущенные nginx-ом сайты.
На самом деле, потому что запускать dotnet run в консоли и вечно держать эту вкладку открытой грустно. Именно поэтому процесс будем демонизировать, то есть настроем автозапуск после перезагрузки и автоматическую работу в фоне с помощью systemd.
Назовём его kestrel-test:
И положим в него следующее содержимое:
[Service]
WorkingDirectory=/home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish #путь к publish папке вашего приложения
ExecStart=/usr/bin/dotnet /home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish/test-lesson.dll # путь к опубликованной dll
Restart=always
RestartSec=10 # Перезапускать сервис через 10 секунд при краше приложения
SyslogIdentifier=dotnet-example
User=root # пользователь, под которым следует запускать ваш сервис
Environment=ASPNETCORE_ENVIRONMENT=Production
Теперь включим и запустим сервис при помощи следующих команд:
Проверим статус сервиса:
Если всё было сделано правильно, на эта команда выдаст нам следующее:
Размещение ASP.NET Core в операционной системе Linux с Apache
Из этого руководства вы узнаете, как настроить Apache в качестве обратного прокси-сервера в CentOS 7, чтобы перенаправлять трафик HTTP в веб-приложение ASP.NET Core, работающее на сервере Kestrel. Расширение mod_proxy и связанные с ним модули создают обратный прокси-сервер.
Предварительные требования
Перезапустить приложения ASP.NET Core, размещенные на сервере, можно в любой момент после обновления общей платформы.
Публикация и копирование приложения
Если приложение запускается локально и не настроено для безопасного подключения (HTTPS), следует применять один из следующих подходов.
Запустите dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release/ /publish), который может выполняться на сервере:
Скопируйте приложение ASP.NET Core на сервер с помощью инструмента, интегрированного в ваш рабочий процесс (например, SCP или SFTP). Обычно веб-приложения находятся в каталоге var (например, var/www/helloapp).
Если развертывание выполняется в рабочей среде, рабочий процесс непрерывной интеграции автоматически опубликует приложение и скопирует его ресурсы на сервер.
Настройка прокси-сервера
Обратный прокси-сервер — это стандартный вариант настройки для обслуживания динамических веб-приложений. Обратный прокси-сервер завершает HTTP-запрос и перенаправляет его в приложение ASP.NET.
Прокси-сервер перенаправляет запросы клиента на другой сервер, а не обрабатывает их самостоятельно. Обратный прокси-сервер перенаправляет запросы в фиксированное назначение обычно от имени клиентов. В этом руководстве мы настроим Apache в качестве обратного прокси-сервера, который работает на том же сервере, где Kestrel предоставляет приложение ASP.NET Core.
Любой компонент, который зависит от схемы, например проверка подлинности, генерация ссылок, перенаправление и геолокация, должен находиться после вызова ПО промежуточного слоя перенаправления заголовков.
ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.
Прокси-серверы под управлением петлевых адресов ( 127.0.0.0/8, [::1] ), включая стандартные адреса localhost (127.0.0.1), считаются доверенными по умолчанию. Если запросы между Интернетом и веб-сервером обрабатывают другие прокси-серверы или сети организации, добавьте их в список KnownProxies или KnownNetworks с помощью ForwardedHeadersOptions. Следующий пример добавляет доверенный прокси-сервер с IP-адресом 10.0.0.100 в ПО промежуточного слоя для перенаправления заголовков KnownProxies в Startup.ConfigureServices :
Установка Apache
Обновите пакеты CentOS до последних стабильных версий:
Установите веб-сервер Apache на CentOS, выполнив одну команду yum :
Пример выходных данных этой команды:
В нашем примере выходные данные содержат строку httpd.86_64, так как используется 64-разрядная версия CentOS 7. Чтобы проверить, где установлен Apache, выполните whereis httpd из командной строки.
Настройка Apache
Создайте для приложения файл конфигурации с именем helloapp.conf:
Мониторинг приложения
Создание файла службы
Создайте файл определения службы.
Пример файла службы для приложения:
Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли считать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:
Сохраните файл и включите службу.
Запустите службу и убедитесь, что она работает.
Теперь, когда обратный прокси-сервер настроен и Kestrel управляется через systemd, веб-приложение можно считать полностью настроенным и оно доступно через http://localhost в браузере на локальном компьютере. Заголовок ответа Server показывает, что приложение ASP.NET Core обслуживается Kestrel.
Просмотр журналов
Защита данных
Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.
Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:
Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.
Защита приложения
Настройка брандмауэра
Firewalld — это динамическая управляющая программа брандмауэра, которая поддерживает зоны сети. Фильтрацию портов и пакетов можно по-прежнему осуществлять через iptables. Firewalld обычно устанавливается в системе по умолчанию. yum позволяет установить этот пакет или убедиться, что он установлен.
С помощью firewalld вы можете открыть только те порты, которые необходимые для работы приложения. В этом случае используются порты 80 и 443. Следующие команды назначают порты 80 и 443 постоянно открытыми.
Конфигурация HTTPS
Настройка приложения для безопасных (HTTPS) локальных подключений
Команда dotnet run использует файл приложения Properties/launchSettings.json, который настраивает приложение для прослушивания URL-адресов, заданных свойством applicationUrl (например, https://localhost:5001;http://localhost:5000 ).
Настройте приложение для использования при разработке сертификата для команды dotnet run или среды разработки (F5 или CTRL + F5 в Visual Studio Code), используя один из следующих подходов.
Настройка обратного прокси-сервера для безопасного подключения клиентов (HTTPS)
Конфигурация безопасности в этом разделе представляет собой общую конфигурацию, которая будет использоваться в качестве отправной точки для дальнейшей настройки. Мы не можем обеспечить поддержку инструментов, серверов и операционных систем сторонних производителей. Ответственность за использование конфигурации в этом разделе лежит на пользователе. Дополнительные сведения см. в следующих ресурсах:
Чтобы принудительно использовать HTTPS, установите модуль mod_rewrite для перезаписи URL-адресов:
Измените файл helloapp.conf, чтобы разрешить безопасный обмен данными через порт 443.
В следующем примере не выполняется настройка сервера для перенаправления небезопасных запросов. Рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS. Для получения дополнительной информации см. Принудительное применение HTTPS в ASP.NET Core.
Для сред разработки, в которых безопасное перенаправление обрабатывается конфигурацией сервера, а не ПО промежуточного слоя перенаправления HTTPS, рекомендуется использовать временные перенаправления (302), а не постоянные перенаправления (301). Кэширование ссылок может привести к нестабильной работе в средах разработки.
При добавлении заголовка Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS. Рекомендации по настройке заголовка Strict-Transport-Security см. в разделе Принудительное применение HTTPS в ASP.NET Core.
В этом примере используется локально созданный сертификат. В SSLCertificateFile должен быть указан основной файл сертификата для доменного имени. В SSLCertificateKeyFile должен быть указан файл ключа, сформированный при создании CSR. В SSLCertificateChainFile должен быть указан файл промежуточного сертификата (если он существует), предоставленный центром сертификации.
Для работы с веб-сервером TLS 1.3 с OpenSSL 1.1.1 требуется сервер Apache HTTP Apache 2.4.43 или более поздней версии.
В предыдущем примере ассоциация протокола OCSP отключена. Дополнительные сведения и рекомендации по включению OCSP см. в разделе об ассоциации OCSP (документация по Apache).
Сохраните файл и протестируйте конфигурацию.
Дополнительные предложения Apache
Перезапуск приложений после обновления общей платформы
После обновления общей платформы на сервере перезапустите размещенные на нем приложения ASP.NET Core.
Дополнительные заголовки
Для защиты от вредоносных атак следует изменить или добавить несколько заголовков. Убедитесь, что модуль mod_headers установлен.
Защита Apache от атак кликджекинга
Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.
Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.
Измените файл httpd.conf.
Сканирование типа MIME
Измените файл httpd.conf.
Балансировка нагрузки
В этом примере показано, как установить и настроить Apache в CentOS 7 и Kestrel на одном компьютере. Чтобы устранить единую точку отказа, воспользуйтесь mod_proxy_balancer и измените значение VirtualHost для управления несколькими экземплярами веб-приложений за прокси-сервером Apache.
Ограничения скорости
С помощью элемента mod_ratelimit, который входит в модуль httpd, можно ограничить пропускную способность для клиентов:
В примере файла пропускная способность составляет 600 Кбит/с в корневой папке.
Длинные поля заголовка запроса
Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 8190 байт. Приложению могут потребоваться более длинные поля (например, приложениям, использующим Azure Active Directory). В этом случае требуется скорректировать директиву LimitRequestFieldSize для прокси-сервера. Применяемое значение зависит от конкретного сценария. Дополнительные сведения см. в документации сервера.
Не увеличивайте значение LimitRequestFieldSize по умолчанию, если это не требуется. Увеличение значения повышает риск переполнения буфера и атак типа «отказ в обслуживании» (DoS) со стороны злоумышленников.