2016-02-03 18 views
7

Ich schreibe eine Intranet-Anwendung. Zielframework in project.json ist dnx451. Das ist mein Verlags Befehl:ASP.NET CORE 1.0, Imitation

dnu publish --runtime dnx-clr-win-x86.1.0.0-rc1-update1 --no-source 

Database Connection String:

Server=name;Database=name;Trusted_Connection=True; 

Ich versuche, den Zugriff auf die Datenbank zu imitieren, aber es funktioniert nicht. Wenn ich die Anwendung starte, wird mein Windows-Benutzer erkannt und es heißt Hello, Domäne \ Benutzername oben rechts. Sobald ich versuche, auf die Datenbank zuzugreifen, erhalte ich den Fehler "Anmeldung fehlgeschlagen für Benutzerdomäne \ Computername". Wenn ich den Anwendungspool unter meinem Benutzer ausführe, funktioniert alles einwandfrei.

IIS: .NET CLR Versio ist v4.0, Managed Pipline-Modus Classic und Identity ist ApplicationPoolIdentity. Website-Authentifizierung: ASP.NET-Identitätswechsel und Windows-Authentifizierung sind aktiviert.

Was muss ich ändern, damit der Identitätswechsel endlich funktioniert?

Antwort

7

Core unterstützt keine Identitätswechsel, da der gesamte Webcode nicht von proc stammt und von Kestrel gehostet wird. Wenn Sie es tun wollen, müssen Sie den aktuellen Principal als WindowsPrincipal, dann manually impersonate an der Stelle, wo Sie es brauchen.

Eine Sache zu beachten ist, dass in RC1 Sie kein WindowsPrincipal erhalten, so dass Sie dies jetzt nicht tun können. Es wird in RC2 behoben werden.

+0

Die Lösung von blowdart funktioniert, ich habe es gerade gegen RC1 getestet. Ich habe eine aktualisierte Version von 4.5.1 verwendet: http://impersonation.codeplex.com/, von der ich glaube, dass sie aus dem gleichen MSDN-Beispiel stammt, das es schon seit einiger Zeit gibt. –

+0

@blowdart: Ist es immer noch Kern, auch wenn ich nur dnx-clr anvisiere? – Dani

+0

Ja, es ist immer noch Kern – blowdart

7

Wenn Sie möchten, dass jede Seitenanforderung die Identität des Benutzers annimmt, können Sie Ihre eigene Middleware so konfigurieren, dass sie vor MVC ausgeführt wird.

public class Impersonate 
{ 
    private readonly RequestDelegate next; 
    public Impersonate(RequestDelegate next) { 
     this.next = next; 
    } 
    public async Task Invoke(HttpContext context) { 
     var winIdent = context.User.Identity as WindowsIdentity; 
     if (winIdent == null) { 
      await next.Invoke(context); 
     }else { 
      WindowsIdentity.RunImpersonated(winIdent.AccessToken,() => { 
       next.Invoke(context).Wait(); 
      }); 
     } 
    } 
} 

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { 
    .... 
    app.UseMiddleware<Impersonate>(); 
    app.UseMvc(...); 
    ... 
} 
+1

dieser Code scheitert wunderschön mit dem neuesten stabilen Kern mvc = ( –

+1

) Entschuldigung, ich hatte versehentlich versucht, den nächsten Handler asynchron aufzurufen, was nur bedeutete, dass der Identitätswechsel wahrscheinlich nur bis zum ersten erwarteten E/A-Aufruf galt zurückgegeben werden, würde RunImpersonated zurückgeben und wir würden auf den Rest der Webpipeline warten, stattdessen muss der Identitätswechsel den Anfragethread blockieren, bis der nächste Delegat abgeschlossen ist (wie oben bearbeitet?). Es kann jedoch immer noch Async-Code vorhanden sein auf einem anderen Thread ... –