Почему перенаправления на моем сайте приводят меня к azure.websites.net вместо моего домена? - PullRequest
Новая
       34

Почему перенаправления на моем сайте приводят меня к azure.websites.net вместо моего домена?

0 голосов
/ 01 октября 2018

Я настроил свое веб-приложение на тайм-аут в режиме ожидания, установив в файле Startup.auth.cs следующее: 

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
     ExpireTimeSpan = TimeSpan.FromHours(1),
     AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
     LoginPath = new PathString("/Account/Login"),
     SlidingExpiration = true,
     ....
}

Мое веб-приложение находится за виртуальной сетью ---> Шлюз приложений,AG направляет запросы в веб-приложение.У меня также есть правила, которые запрещают прямой доступ (т.е. myapp.azurewebsites.com) к веб-приложению.

Теперь, когда время сеанса истекло, я перенаправлен на:

https://myapp.azurewebsites.net/Account/Login?ReturnUrl=%2Fcustomerarea

, то есть синий экран с ошибкой 403 (правильная ошибка), вместо моего собственного домена, например:

https://example.com/Account/Login?ReturnUrl=%2Fcustomerarea

Кто-нибудь знает, почему у меня такое поведение?спасибо.

Редактировать : больше информации ... похоже, что любое перенаправление вызывает вышеуказанную проблему.Поэтому, если я ввожу URL https://example.com/customerarea, который требует от пользователя входа в систему, то в перенаправленном URL-адресе на страницу входа будет указан адрес azurewebsites.net.

Ответы [ 2 ]

0 голосов
/ 02 октября 2018

Таким образом, приведенный выше ответ является правильным.Я добавляю больше информации о том, как это решает проблему в веб-приложении MVC 5.В соответствии с Часто задаваемые вопросы по шлюзу приложений Microsoft :

Шлюз приложений также вставляет заголовок X-Original-Host, который содержит исходный заголовок Host, с которым поступил запрос.Этот заголовок полезен в сценариях, таких как интеграция с веб-сайтом Azure, где заголовок входящего узла изменяется до того, как трафик направляется на сервер.

Поэтому, чтобы исправить это, я добавил следующий код в верхней части моего Configuration (IAppBuilder app) метод в файле start.cs: 

app.Use(async (context, next) =>
{
  if (context.Request.Headers.GetValues("X-Original-Host") != null)
  {
    var originalHost = context.Request.Headers.GetValues("X-Original-Host").FirstOrDefault();
    context.Request.Headers.Set("Host", originalHost);
  }
  await next.Invoke();
});
0 голосов
/ 02 октября 2018

Любые перенаправления без явных частей хоста в экосистеме ASP.NET будут переходить на часть хоста, предоставленную текущим HttpContext.Request.

Ваш шлюз приложения сделает окончательный запрос к вашему приложению (например, прокси)) и обращается к нему как к вашему домену .azurewebsites.net → это означает, что ваше приложение ASP.NET не знает об исходном запросе к шлюзу.

Что вам нужно будет сделать, это установить имя хоста входящего запроса висходное имя хоста из запроса, отправленного на ваш шлюз приложений.

Эта страница документации (Это ASP.NET Core, но тот же принцип справедлив для asp.net-mvc-5)должно позволить вам получить представление о том, как перезаписать ваше входящее имя хоста HttpContext.Request к оригиналу.Есть, конечно, несколько способов.

  1. Переадресованные заголовки (которые затем должны быть установлены вашим шлюзом приложений)
  2. Запись конфигурации (наличие записи конфигурации с «жестко закодированным» именем хоста).)

Оба подхода просто потребуют дополнительного промежуточного программного обеспечения для переопределения текущего запроса в соответствии с информацией, собранной любым из этих подходов.

...