Я пытаюсь создать промежуточную среду для веб-приложения ASP.NET MVC, но я сталкиваюсь с проблемой, последняя из которых была такой: Ошибка HTTP 500.79 / System.UriFormatException при развертывании ASP. NET приложение для веб-приложения Azure
В настоящее время я получаю HTTP 403 - Запрещено: «У вас нет разрешения на просмотр этого каталога или страницы». ошибка при попытке доступа к странице.
В отношении аутентификации приложение использует Azure Active Directory в качестве поставщика аутентификации, который отлично работает при локальном тестировании (с использованием Test-AAD) и в производстве. Локальные и производительные приложения не используют Azure Web Apps. На странице службы приложений Azure я заметил, что есть возможность указать аутентификацию прямо в Azure, но я не хочу / не хочу ее использовать, так как все указано в приложении, соответственно. настроен в web.config (ClientID, ClientSecret и Tenant). В любом случае, когда я попытался заполнить аутентификацию в Azure напрямую, она тоже не сработала, поэтому я удалил ее снова.
Что происходит сейчас, так это то, что перенаправление на страницу входа в систему на login.microsoftonline.com работает, и, по мнению администратора AAD, попытка входа успешна или, по крайней мере, не показывает никаких особенностей. Однако при перенаправлении обратно на мою страницу я получаю общий 403, без какой-либо дополнительной информации, которая могла бы помочь выявить проблему.
Я проверил все виды журналов для получения дополнительной информации, и единственная особенность, которую я обнаружил, заключается в том, что по какой-то очень странной причине все запросы направляются на совершенно бессмысленный URL:
Запрошенный URL / указанный URL ответа: https:\\skillmanagementtest.azurewebsites.net
Фактически запрошенный URL согласно журналам: https:\\Skillmanagementtest:80
Я абсолютно не знаю, откуда этот URL-адрес, однако Skillmanagementtest с такой заглавной буквой выглядит как имя, указанное для веб-приложения Azure:
Элементы скриншотов группы ресурсов
Файл web.config должным образом преобразуется во время конвейера CI / CD, и я дважды проверил там параметры аутентификации (tenant, clientID, clientSecret), и я действительно не знаю, что может быть причиной этой проблемы.
Один совет, который я обнаружил по другим проблемам, состоял в проверке журналов IIS, но когда я попытался получить доступ к каталогу, эти журналы, как говорили, были помещены в меня, мне было отказано в доступе, даже если у меня есть разрешения владельца в службе приложений ...
UPDATE
После долгого и утомительного процесса пробовать вещи и обсуждать, мы наконец-то запустили приложение. Некоторые наблюдения, которые мы сделали, которые могут быть интересны для других с этой или аналогичными проблемами:
- Ролевая авторизация не сработала, поскольку мы забыли указать роли приложения в файле манифеста регистрации приложения, а затем связать группы безопасности с ролями приложения. Проверьте здесь для получения дополнительной информации: https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
- У нас был один API, который виден только в домене нашей компании. Поскольку веб-приложение Azure работает за пределами этого домена, попытка доступа к этому API привела к внутренней ошибке сервера. Нам все еще нужно найти решение для этого.
- У нас была ситуация, когда запросы на ответный URL после авторизации перенаправлялись с HTTPS на HTTP. Мы решили это, но так как пять человек последовательно пробовали что-то, мы в настоящее время не знаем, что на самом деле было исправление. Мы можем создать другое веб-приложение Azure, которое затем может раскрыть эту часть решения.