Ошибка HTTP 403 при развертывании приложения ASP.NET в Azure Web App
Я пытаюсь создать промежуточную среду для веб-приложения ASP.NET MVC, но спотыкаюсь от проблемы к проблеме, последняя из которых была одна: HTTP 500.79 Ошибка / System.UriFormatException при развертывании приложения ASP.NET в Azure Web App
В настоящее время я получаю 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, но когда я попытался получить доступ к каталогу, эти журналы, как говорили, были помещены в меня, мне было отказано в доступе, даже если у меня есть разрешения владельца в службе приложений...
ОБНОВИТЬ
После долгого и утомительного процесса пробовать вещи и обсуждать, мы наконец запустили приложение. Мы сделали некоторые наблюдения, которые могут быть интересны для других с этой или схожими проблемами:
- Авторизация на основе ролей не сработала, поскольку мы забыли указать роли приложения в файле манифеста регистрации приложения, а затем связать группы безопасности с ролями приложения. Проверьте здесь для получения дополнительной информации: 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, которое затем может раскрыть эту часть решения.
2 ответа
После долгого и утомительного процесса пробовать вещи и обсуждать, мы наконец запустили приложение. Мы сделали некоторые наблюдения, которые могут быть интересны для других с этой или схожими проблемами:
- Авторизация на основе ролей не сработала, поскольку мы забыли указать роли приложения в файле манифеста регистрации приложения, а затем связать группы безопасности с ролями приложения. Проверьте здесь для получения дополнительной информации: 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, которое затем может раскрыть эту часть решения.
Убедитесь, что то, что у вас есть в ваших web.config и настройках приложения, совпадает с тем, что есть в ответных URL для регистрации вашего приложения на портале. Там может быть какая-то ссылка, где URL ответа не совпадает.
Вы используете образец openid? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Также убедитесь, что вы входите в систему с пользователем, у которого есть права доступа в соответствии с арендатором и самим приложением. Мы с коллегой сделали короткое видео, в котором указаны правильные конфигурации, которые могут быть полезны для этого варианта использования. https://www.youtube.com/watch?v=MohaxN6fsDs