#asp.net-mvc #azure-front-door
Вопрос:
Я управляю ASP.NET Приложение MVC в службе приложений Azure с входной дверью.
Входная дверь настроена с пользовательским доменом и указывает на сайты myapp.azurewebsites.сеть как серверная часть.
Собираюсь mysite.mydomain.com показывает ожидаемую страницу, но хост записывает сайты myapp.azurewebsites.сеть в качестве URL — адреса запроса вместо mysite.mydomain.com.
Эта проблема влияет на внешний логин Google, который использует строку пути для установки моего возврата в myapp.azurewebsites.net/signin-google и мое ведение журнала, в котором используется запрос.Url-адрес для входа на запрошенную страницу.
Ответ №1:
Конфигурация серверной части в пуле серверной части входной двери включает поле заголовка серверного узла, которое определяет имя хоста, используемое для пересылаемых запросов. По умолчанию для этого задано имя серверного хоста, что означает, что все запросы, пересылаемые на этот сервер, будут отображаться на серверном сервере под его собственным именем хоста. Вы можете либо изменить значение этого поля на другое имя хоста (например mysite.mydomain.com , в вашем примере), либо оставить его пустым, чтобы всегда использовать имя хоста запроса.
Ознакомьтесь с документацией по этой теме здесь.
Как отмечалось в комментариях, ваш сервер должен иметь возможность принимать запросы под пользовательским именем хоста. В случае веб-приложения Azure это также означает добавление пользовательского имени хоста в веб-приложение.
Комментарии:
1. Изменение заголовка внутреннего хоста на mysite.mydomain.com или пустые результаты на веб-сайте, не найденном для mysite.mydomain.com. В связанной документации также указано: Для большинства бэкендов приложений (веб-приложений Azure, хранилища больших двоичных объектов и облачных служб) требуется, чтобы заголовок хоста соответствовал домену бэкенда.
2. @стефан, Входная дверь меняет только имя хоста, указанное в запросе. Вам все равно нужно будет выполнить все обычные действия, необходимые для того, чтобы сделать ваше веб-приложение доступным под определенным именем хоста (например, добавить пользовательский домен в ваше веб-приложение). В принципе, если он будет доступен под вашим пользовательским именем хоста без Входной двери, то изменение заголовка хоста входной двери на ваш пользовательский домен не должно вызывать проблем. В настоящее время у меня работает эта настройка для двух веб-приложений, и она работает нормально, хотя, конечно, ваша ситуация все равно может быть другой.
3. Я добавил mysite.mydomain.com как пользовательский домен для моей службы приложений, и теперь он работает. Необходимо ли добавлять сертификат в этот пользовательский домен для безопасного соединения между входной дверью и службой моего приложения?
4. @стефан Я на самом деле не уверен, но я думаю, что Входная дверь подключится к веб-приложению с помощью того, что указано в
Backend host nameполе, которое в случае*.azurewebsites.netимени хоста уже защищено, независимо от того, будет ли ваше пользовательское имя хоста безопасным. Тем не менее, если предположить, что у вас уже есть сертификат для защиты входной двери, добавление сертификата в ваше веб-приложение может не вызвать особых проблем и может стоить того «на всякий случай».5. Я обновил свой ответ примечанием о добавлении пользовательского имени хоста в веб-приложение.