1

Face à un comportement étrange aujourd'hui. Nous hébergeons l'application Web asp.net core 1.1 avec Azure App Services et l'utilisation de sous-domaines qui acheminent vers un contrôleur ou une zone spécifique. Donc, dans mon SubdomainConstraint: IRouteConstraint J'utiliseService ASP.NET Core Azure App httpContext.Request.Headers ["Host"] Valeur

HttpContext.Request.Headers["Host"] 

pour obtenir le nom d'hôte. Ce smth précédemment retourné comme

mywebsite.com or subdomain.mywebsite.com 

À partir d'aujourd'hui (ou peut-être hier) il a commencé à retourner mon nom service App au lieu du nom d'hôte. Sur localhost tout fonctionne bien. Énumération par

Context.Request.Headers 

dans un de mes vues me donne sur localhost:

Accept : 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
Accept-Encoding : gzip, deflate, sdch, br 
Accept-Language : ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4,ca;q=0.2 
Cookie : .AspNetCore.Antiforgery.... 
Host : localhost:37202 
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 
Upgrade-Insecure-Requests : 1 

Azure service App:

Connection : Keep-Alive 
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 
Accept-Encoding : gzip, deflate, sdch 
Accept-Language : ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4,ca;q=0.2 
Cookie : AspNetCore.Antiforgery.... 
Host : mydeploymentname:80 
Max-Forwards : 10 
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 
Upgrade-Insecure-Requests : 1 
X-LiveUpgrade : 1 
X-WAWS-Unencoded-URL :/
X-Original-URL :/
X-ARR-LOG-ID : 9c76e796-84a8-4335-919c-9ca4rb745f4fefdfde 
DISGUISED-HOST : mywebsite.com 
X-SITE-DEPLOYMENT-ID : mydeploymentname 
WAS-DEFAULT-HOSTNAME : mydeploymentname.azurewebsites.net 
X-Forwarded-For : IP:56548 
MS-ASPNETCORE-TOKEN : a97b93ba-6106-4301-87b2-8af9a929d7dc 
X-Original-For : 127.0.0.1:55602 
X-Original-Proto : http 

je peux obtenir ce que je besoin de

Headers["DISGUISED-HOST"] 

Mais ayant des problèmes avec les redirections vers une page de connexion, il redirige vers la mauvaise URL avec mon nom de déploiement. Je me demandais si je pouvais gâcher quelque chose n'importe où. Mais nous avons fait le dernier déploiement il y a quelques jours et cela a bien fonctionné par la suite.

+0

Pouvez-vous partager votre nom d'application web, que ce soit directement ou [indirectement] (https://github.com/projectkudu/kudu/wiki/Reporting-your-site-name-without-posting-it-publicly)? Cela nous aidera à enquêter. Merci! –

+0

J'ai le même problème, Microsoft étudie. – argaz

+0

A été résolu pour moi. – argaz

Répondre

2

Ceci est dû à une régression dans AspNetCoreModule déployée sur un petit nombre d'applications dans Azure App Service. Ce problème est en cours d'investigation. Veuillez suivre le this thread pour le statut.

Voici une solution de contournement, vous pouvez utiliser jusqu'à ce que le correctif est déployé: dans votre méthode Configurer (généralement dans startup.cs), ajoutez ce qui suit:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
    { 
     app.Use((ctx, next) => 
     { 
      string disguisedHost = ctx.Request.Headers["DISGUISED-HOST"]; 
      if (!String.IsNullOrWhiteSpace(disguisedHost)) 
      { 
       ctx.Request.Host = new Microsoft.AspNetCore.Http.HostString(disguisedHost); 
      } 
      return next(); 
     }); 

     // Rest of your code here... 

    } 
+0

Toute mise à jour sur quand cela sera corrigé? Cela affecte quelques-unes de nos applications déployées dans l'Ouest des États-Unis. –