Wir führen eine AngularJS-Anwendung auf JBoss WildFly aus. Sie funktionierte sowohl in unserer Testumgebung als auch in der Produktion einwandfrei. Jetzt gibt es jedoch in der Produktion ein seltsames 403-Fehlerproblem.
Benutzer können Daten per REST-Anfrage laden. Auf einer Site wird ein Cookie gesetzt, um eine Filteroption zu speichern. Sobald das Cookie gesetzt ist, schlagen alle nachfolgenden Anfragen fehl und es wird ein Fehler 403 (Verboten) angezeigt.
Lokal und auf unserem Remote-Testserver gibt es dieses Problem nicht. In der Produktion hat es auch funktioniert, aber irgendetwas muss sich geändert haben. Es passiert in allen Browsern und bei allen Benutzern, also gehe ich davon aus, dass unsere IT-Abteilung die Serverkonfiguration geändert haben muss. Ich kann jedoch nicht die Grundursache des Problems herausfinden.
Der Server antwortet mit den folgenden Headern:
Server: Apache
X-Powered-By: Undertow/1
Ich weiß aber, dass wir JBoss WildFly verwenden. Weder im JBoss-Log noch in der Entwicklerkonsole des Browsers finden sich sinnvolle Einträge. Ich verwalte die Serverinfrastruktur nicht, muss dieses Problem aber dringend lösen.
Meine Fragen sind:
Wo protokolliert JBoss die Anfragen an den Webserver? Gibt es hierfür eine zusätzliche Zugriffsprotokolldatei (
/var/log/apache2/error.log
existiert nicht)?Warum behauptet der Header, dass der Server Apache ist? Die
standalone.xml
Datei von JBoss setzt "WildFly/9". Gibt es dazwischen einen anderen Server, der die Anfragen bearbeitet? Wie kann ich das herausfinden?Protokollieren JBoss oder Apache die Ursache solcher Fehler überhaupt? Muss ich die Protokollierungsebenen erhöhen?
Sobald ich das Cookie lösche, funktioniert die Site wieder normal. Ich bin sicher, dass es sich nur um ein kleines Konfigurationsproblem handelt, da es vorher funktioniert hat, aber ich kann es im Moment nicht herausfinden. Ich bin für alle Hinweise sehr dankbar.
Antwort1
Fügen Sie diesen Block zum standalone.xml
Subsystem hinzu urn:jboss:domain:logging:3.0
:
<logger category="org.jboss.security">
<level name="TRACE"/>
</logger>
Starten Sie den Server neu, damit er die neue Konfiguration übernimmt.
Führen Sie jetzt Interaktionen durch, um Fehler 403 zu verursachen. Genauere Informationen werden server.log
jetzt in einer Datei protokolliert. Dadurch konnte ich zumindest Einzelheiten zur Grundursache des Problems erfahren. Scheint so, als ob die Zuordnung von Rollen aus Active Directory fehlschlägt. Muss das aber noch weiter untersuchen.
Aber zumindest hat mir das Erhöhen des Protokolllevels, wie oben beschrieben, beim Debuggen geholfen.