2016-07-15 17 views
0

Ich versuche waffle-spring-security4 mit einem vorhandenen Spring Boot-Projekt zu integrieren, wo die meisten der Konfiguration automatisch geschieht. Ich habe bemerkt, dass, wenn die NegotiateSecurityFilter in der Kette ist, einige seltsame Dinge auftreten: Ich bekomme ClassNotFoundException beim Initialisieren einer völlig trivialen Klasse mit einer String-Eigenschaft; eine Thymeleaf-Vorlage, die zuvor gut geladen wurde, kann nicht aufgelöst werden und so weiter. Als dies geschah, hatte ich die folgenden Filter in der Kette:Spring Security: plötzlichen Klassenpfad und Thymeleaf Probleme nach dem Ändern der Filterkette

  1. WebAsyncManagerIntegrationFilter
  2. SecurityContextPersistenceFilter
  3. HeaderWriterFilter
  4. CsrfFilter
  5. LogoutFilter
  6. NegotiateSecurityFilter (von Waffel)
  7. BasicAuthenticationFilter
  8. RequestCacheAwareFilter
  9. SecurityContextHolderAwareRequestFilter
  10. SessionManagementFilter
  11. ExceptionTranslationFilter
  12. FilterSecurityInterceptor

mit auf eine HTTP-Basic-Authentifizierung Zurückschalten das Problem verschwindet, so dass ich denke, das Problem mit den Filtern oben sein könnte. Haben Sie eine Idee, wie Sie dies beheben können? (Wenn Sie irgendeine Strategie zum Debuggen ähnlicher Probleme haben, wäre das ausgezeichnet.)

+0

nur eine Ahnung: vielleicht ist es ein Abhängigkeitsproblem - Waffel-Frühling-security4 hat Frühjahr Sicherheitsabhängigkeiten ... als erstes, was Sie überprüfen können, ob seine Abhängigkeit Version mit der Feder Sicherheitsversion kollidieren, die Sie bereits verwendet haben ... hoffe, das hilft – kukkuz

+0

@kukkuz Ja, ich habe das schon überprüft, aber da ich den Security-Starter benutze, habe ich dort nicht viele Probleme erwartet. – Scorchio

Antwort

0

Ja, es wurde von Waffle verursacht, wie sich herausgestellt hat.

Das Problem war, dass, sobald Sie eine erfolgreiche Authentifizierung mit Waffle, für den Rest des Laufs, die notwendigen Dateien waren nicht zugänglich gemacht. Dies führte dazu, dass alles, was versuchte, etwas vom Klassenpfad zu laden, kläglich versagte. Ich muss hier hinzufügen, dass ich versucht habe, dies von der Quelle mit gradle bootRun auszuführen und das jar zu bauen und das stattdessen zu laufen; Im ersten Fall scheiterte die Thymeleaf-Resolution, in der zweiten wurde keine Spring-Klasse gefunden.

Es stellt sich heraus, dass wenn der entfernte Benutzer (der sich über SSO anmeldet) keinen Lesezugriff auf die Dateien hat, sobald der Benutzer authentifiziert ist, wird die Anwendung überhaupt nicht mehr normal funktionieren! Ich war mir dieser Umweltveränderung, die durch Waffle verursacht wurde, nicht bewusst, da ich mich nicht daran erinnern kann, dass ich etwas darüber in den Dokumenten gesehen habe - aber es macht Sinn. Nachdem ich dem Benutzer Lesezugriff gewährt hatte, begann es zu arbeiten.