it-swarm.com.de

ASP.NET Core 2.0-HttpSys-Windows-Authentifizierung schlägt mit dem Attribut Authorize fehl (InvalidOperationException: Es wurde kein authenticationScheme angegeben)

Ich versuche, eine ASP.NET Core 1.1-Anwendung auf ASP.NET Core 2.0 zu migrieren.

Die Anwendung ist ziemlich einfach und umfasst Folgendes:

  • Gehostet auf HttpSys (ehemals WebListener)
  • Verwenden der Windows-Authentifizierung: options.Authentication.Schemes = AuthenticationSchemes.NTLM
  • Anonyme Authentifizierung zulassen: options.Authentication.AllowAnonymous = true (da es einige Controller gibt, die keine Authentifizierung erfordern)
  • Controller, die eine Authentifizierung erfordern, sind mit dem Symbol [Authorize] Attribut.

Das Projekt wird kompiliert und startet einwandfrei. Es werden auch Aktionen von Controllern bedient, für die keine Authentifizierung erforderlich ist.

Sobald ich jedoch einen Controller mit dem [Authorize] Attribut erhalte ich die folgende Ausnahme:

System.InvalidOperationException: No authenticationScheme was specified,
and there was no DefaultChallengeScheme found.
   at Microsoft.AspNetCore.Authentication.AuthenticationService.<ChallengeAsync>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.ChallengeResult.<ExecuteResultAsync>d__14.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeResultAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeFilterPipelineAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.<InvokeAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__7.MoveNext()

Ich fing an, mit den Projektvorlagen herumzuspielen, und bemerkte, dass ich dies mit der Standardvorlage ASP.NET Core-Webanwendung (Model-View-Controller) leicht reproduzieren konnte mit Windows-Authentifizierung.

Die Program.cs-Datei wurde wie folgt geändert:

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseHttpSys(options =>
            {
                options.Authentication.Schemes = AuthenticationSchemes.NTLM;
                options.Authentication.AllowAnonymous = true;
                options.MaxConnections = 100;
                options.MaxRequestBodySize = 30000000;
                options.UrlPrefixes.Add("http://localhost:5000");
            })
            .UseStartup<Startup>()
            .Build();

Dies kommt direkt aus der HttpSys-Dokumentation . Auch ich fügte hinzu, die [Authorize] Attribut der Klasse HomeController. Jetzt wird genau die gleiche Ausnahme wie gezeigt erzeugt.

Ich habe einige verwandte Stapelüberlauf-Posts gefunden ( hier , hier und hier ), aber keine befasst sich mit einfacher Windows-Authentifizierung (und die Antworten tun dies) scheinen nicht zu verallgemeinern).

18
Andreas

Während ich den Beitrag schrieb, fiel mir ein, dass ich diesen Unterabschnitt des Migrationsleitfadens gefunden hatte. Es heißt, hinzuzufügen

services.AddAuthentication(Microsoft.AspNetCore.Server.IISIntegration.IISDefaults.AuthenticationScheme);

auf die Funktion ConfigureServices.

Anfangs dachte ich, dass dies nicht für HttpSys gilt, wenn man den vollständigen Namen der Konstante angibt (besonders das IISIntegration hat mich abgeworfen). Darüber hinaus wird dies in der HttpSys-Dokumentation zum jetzigen Zeitpunkt überhaupt nicht erwähnt.

Für diejenigen, die auf das vollständige .NET Framework abzielen, ist die Installation des NuGet-Pakets Microsoft.AspNetCore.Authentication Erforderlich.

[~ # ~] edit [~ # ~]

Wie Tratcher betont, gibt es eine ähnliche Konstante aus dem Namensraum HttpSys, die Sie lieber verwenden sollten:

Microsoft.AspNetCore.Server.HttpSys.HttpSysDefaults.AuthenticationScheme
26
Andreas

Die Antwort von Andreas brachte mich auf den richtigen Weg, aber das hat bei mir funktioniert:

Paketverweis auf Microsoft.AspNetCore.Authentication Hinzugefügt

und dann für Startup.cs

using Microsoft.AspNetCore.Server.IISIntegration;

public void ConfigureServices(IServiceCollection services)
{
    ...
    services.AddAuthentication(IISDefaults.AuthenticationScheme);
    ...
}
7
fiat

Eine andere Sache, wenn Sie bereits hinzugefügt services.AddAuthentication (IISDefaults.AuthenticationScheme); Stellen Sie sicher, dass Sie einen Authentifizierungstyp (Fenster, Formulare) in iis unter App -> Authentifizierung aktivieren. Meine waren alle deaktiviert und bekamen diesen Fehler, obwohl der Code vorhanden war.

1
joel1618