Domanda
Sto cercando di sostituire un servizio Web che fornisce informazioni a un'applicazione mobile via ODATA 4. L'applicazione corrente utilizza EF6 e funziona senza errori.
Successivamente ho creato un NUOVO .NET Core 2.1.1, utilizzando EF 2.1 e Core Odata 7.0.1. Tutto sembra funzionare come proprietà quando si esegue IISExpress tramite l'interfaccia di Visual Studio 2017.
Problema DI DEPLOYMENT?:
Il problema sembra essere nella distribuzione su un server IIS. Ho installato tutti i runtime corretti e i pacchetti di hosting. Altro .NET Core 2.1 che utilizza applicazioni EF 2.1 (pagine Web, non servizi) funziona senza problemi. Questo servizio, tuttavia, avvierà la pagina $ metadata e avvierà correttamente la pagina di interfaccia iniziale. Una volta chiamato qualsiasi controller che dispone di una connessione EF, ricevo solo una pagina parziale ... Non vi sono errori nei registri eventi L'unico "EVENT" che effettivamente ricevo è una voce "Informazioni" nel "Registro applicazioni di Windows" del host IIS Server che dice;
Origine: ID evento MSSQLSERVER: 18456
Accesso non riuscito per l'utente 'Dominio \ Server16 $'. Motivo: impossibile trovare un login corrispondente al nome fornito. [CLIENTE: 192.168.1.16]
La stringa di connessione SQL si trova nel file appsettings.json e questa stringa di connessione funziona all'interno dello stesso studio visivo ... Tutto questo si verifica dopo la distribuzione su un server IIS effettivo e solo con questo servizio Web, non con altre applicazioni che utilizzano EF 2.1 .
C'è qualcosa che mi è mancato nello sviluppo? È un problema noto? Qualcuno ha un indizio?
Soluzione: (sorta di)
Sono pienamente consapevole che IIS è un front-end "proxy" per il server Kestrel che esegue l'applicazione .NET Core. Detto questo, si potrebbe pensare che il pool di identità dell'applicazione per IIS (l'host) sarebbe irrilevante poiché l'applicazione .NET Core dovrebbe essere "completamente autonoma". Beh ... No ... In effetti, se lasci AppPoolIdentity (il valore predefinito), come hai fatto per tutte le precedenti applicazioni ASP.NET MVC e poi hai creato stringhe di connessione all'interno dei file appsettings.json per motivi di sicurezza, beh questo non lavoro, perché c'è un difetto evidente (IMHO) â € | Nel mio caso d'uso, servizio Web in esecuzione su un back-end di SQL Server, dovrai dare il PROXY, in questo caso l'AppPool IIS che esegue il tuo accesso al servizio stesso database. Quindi, ora devo avere due account che ottengono l'accesso ai servizi di back-end ... Questo sembra essere di breve durata in un mondo attento alla sicurezza!
Risposta popolare
Nonostante la natura a breve termine delle applicazioni .NET Core ospitate da IIS come front-end proxy, sembra che l'AppPool che esegue il proxy IIS richieda l'accesso allo stesso server database che l'account SQL utilizzato per il database richiede ... YUCK !
Grazie a Edward (che ha pubblicato un commento), mi ha portato a questo post:
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow