Cum pot găsi cauza erorii 403.18 în IIS?

Am instalat o nouă aplicație sub IIS. Noua aplicație are un pool de aplicații dedicat, ca multe alte aplicații instalate pe același server. Există site-ul web rădăcină care are și propriul pool de aplicații dedicat. Toate aplicațiile implementate anterior funcționează bine în această configurație, dar cea mai nouă aplicație provoacă o eroare 403.18 când încerc să răsfoiesc la ea.

Dacă navighez la el dintr-o sesiune RDP pe server, primesc pagina de eroare detaliată care include aceste informații:

Eroare HTTP 403.18 - Interzis

Solicitarea specificată nu poate fi procesată în grupul de aplicații care este configurat pentru această resursă pe serverul Web.

Cele mai probabile cauze:

• Un filtru ISAPI sau un modul personalizat a schimbat adresa URL pentru a rula într-un alt grup de aplicații decât adresa URL inițială.
• O extensie ISAPI (sau un modul personalizat) a folosit ExecuteURL (sau ExecuteRequest) pentru a rula într-un alt grup de aplicații decât URL original.
• Aveți o pagină de eroare personalizată care se află într-un grup de aplicații, dar este referită de un site Web dintr-un alt pool de aplicații. Cand URL este - procesat, este determinat de IIS pe care ar trebui să-l aibă au fost procesate în primul pool de aplicații, nu în celălalt pool.
• Site-ul Web are mai multe aplicații configurate. Aplicația în care este configurată această solicitare este setată să ruleze într-o aplicație piscina care nu exista.

Lucruri pe care le puteți încerca:

• Dacă aveți o aplicație care încearcă să proceseze o adresă URL într-un alt grup de aplicații (cum ar fi încercarea de a procesa o eroare personalizată), asigurați-vă că ambele - rulează în același pool de aplicații dacă adecvat.
• Dacă încercați să procesați o adresă URL de eroare personalizată care se află într-un alt grup de aplicații, activați caracteristica de redirecționare a erorilor personalizate.
• Verificați dacă există grupul de aplicații pentru aplicație.
• Creați o regulă de urmărire pentru a urmări solicitările eșuate pentru acest cod de stare HTTP și pentru a vedea dacă ExecuteURL este apelat. Pentru mai multe informații despre crearea unei reguli de urmărire pentru solicitările eșuate, faceți clic aici.

Am rulat urmărirea cererii eșuate, dar practic a repetat aceleași informații și nu părea să ofere nicio perspectivă. Recunosc că nu înțeleg totul din acel fișier de urmărire.

Am încercat să schimb pool-ul de aplicații pentru site-ul rădăcină la același pool ca și aplicația nou implementată. Acest lucru șterge eroarea 403.18, așa că diferența dintre grupurile de aplicații dintre aplicație și site-ul rădăcină pare să aibă ceva de-a face cu aceasta. Cu toate acestea, aplicația nu se încarcă, iar browserul face pur și simplu o listă de director cu conținutul căii fizice.

Lucrul ciudat este că multe alte aplicații de pe acest server rulează foarte bine. Marea diferență cu noua aplicație este că folosește autentificarea .NET 5 și Azure AD.Ceilalți folosesc versiuni anterioare ale .NET Core sau .NET Framework și autentificarea Windows. Am verificat că este instalat pachetul de găzduire .NET 5.

Am încercat să urmăresc lista „Lucruri pe care le puteți încerca” din pagina de eroare și nu par să se aplice.

Există alți pași pe care îi pot încerca sau indicii care m-ar putea ajuta să găsesc cauza principală a acestui lucru? Sunt bucuros să ofer mai multe detalii, dar încă nu sunt sigur ce detalii sunt relevante.

Ei bine, în sfârșit am dat peste cauza acestei erori. Numele aplicației afectate a fost configurat anterior ca director virtual și mai exista o intrare pentru aceasta în fișierul applicationHost.config.

Cea mai nouă versiune a fost implementată ca aplicație. Au existat și alte intrări învechite pentru numele aplicației în fișierul applicationHost.config.

Ceea ce a dat acest lucru este că am încercat să implementez aplicația sub un nume nou care a funcționat. Mi s-a părut ciudat, așa că am comparat applicationHost.config între serverul pe care aplicația a cauzat 403.18 și serverul de dezvoltare unde a funcționat OK.

Adevărata cauză a acestei erori este faptul că am clonat un server web de producție și l-am transformat într-un server web de testare. Aceste intrări nevalide au fost prezente pe serverul de producție. Totuși, a funcționat pentru cel mai bine, pentru că altfel nu am fi lovit acea eroare 403.18 până când am fi implementat în producție.

Prin urmare, verificarea intrărilor nevalide în applicationHost.config este cel puțin unul dintre pașii de depanare care se pot face pentru a rezolva 403.18.