2016-06-30 18 views
1

Wechsel von der containergesteuerten Authentifizierung zum Spring Security-Plugin in einer Grails 3.1.9-App. In der vom Container verwalteten Welt haben unsere Grails-Interzeptoren NACH Authentifizierung für eine gesicherte Ressource ausgeführt. Doch mit Spring Security, die Abfangjäger (mit vor() Logik) ausführen mit der folgenden Sequenz:Können Interceptors zwischen Authentifizierung und Aktionsausführung ausgeführt werden?

  1. Anruf zu gesicherter Ressource
  2. Interceptor Stapel abfängt Anfrage gibt true zurück
  3. Weitergeleitet Login-Seite
  4. zu bilden
  5. Erfolgreiche Authentifizierung
  6. Umleitung angeforderte Ressource

Wir Abfangjäger haben, dass shoul d nur feuern für authentifizierte Benutzer. Gibt es eine Möglichkeit, Interceptors zwischen Schritt 4 & 5 anstelle dieses Flusses auszuführen? Oder muss unsere Interceptor-Logik in Spring Security-Filter verschoben werden?

+0

Ich habe die gleichen Anforderungen wie diese Frage, aber ich konnte der Antwort nicht folgen. Ich habe den Interceptor geschrieben, der gut funktioniert, wenn ich von Intellij oder Grails Run-App laufe, aber wenn ich ihn in Tomcat als Kriegsdatei einsetze, geht die Hölle los. Mein Token wird authentifiziert, aber ich bekomme springSecurityService.principal = null. Details sind in dieser Frage. –

Antwort

2

Es ist ein wenig klarer, wenn Sie den Fluss in einer 2.x-App betrachten, da es eine web.xml-Datei gibt, in der die Reihenfolge einiger der Teile klarer ist, aber im Grunde die gleiche in 2.x und 3.x.

Die Filterkette des Plugins wird als ein Filter registriert und ist so konfiguriert, dass sie nach dem grailsWebRequest Filter, aber vor dem GrailsDispatcherServlet läuft. Dies soll annotierte Controller unterstützen, die URL-Mappings haben, die sich vom Standard unterscheiden (zB PersonController.show() mag /person/show zugeordnet sein, aber die App könnte sie auf jedes gültige uri (und Kombination von REST Verben) abgebildet haben, also muss ich in der Lage sein, die kompilierten URL-Mapping-Instanzen zu durchsuchen, um herauszufinden, welche Controller-Aktion für die aktuelle Anfrage ausgeführt wird.Im Filter weiß ich, welche URL angefordert wird, aber nicht welche Sicherheitsregel (n) anzuwenden ist, wenn alles URL-basiert ist Es wäre einfach und vorkompiliert beim Start, aber mit annotierten Controllern weiß ich nur, welche Regeln für Controller-Methoden gelten.

Das Servlet läuft nach den Filtern, und das ist, wo der Controller bestimmt und aufgerufen wird. Interceptors (und Grails-Filter (nicht zu verwechseln mit Servlet-Filter) in 2.x) sind eigentlich Spring HandlerInterceptors, die com bekommen zusammen mit einem "Handler" in eine HandlerExecutionChain gestellt. Dies ist generisch genug, um mit jeder Art von Anfrage zu arbeiten, aber in der Praxis ist der Handler ein Controller, daher ist der Bereich viel enger, als wenn es ein Servlet-Filter wäre.

Um zu Ihrer eigentlichen Frage zurückzukehren, sollten Sie die Arbeit in einem Filter ausführen, der zur Spring Security-Filterkette hinzugefügt wurde. Diese sind ziemlich einfach zu implementieren und der Prozess ist in der plugin docs beschrieben.

+0

Ich habe dieselben Anforderungen wie diese Frage, aber ich konnte der Antwort nicht folgen. Ich habe den Interceptor geschrieben, der gut funktioniert, wenn ich von "intellij" oder "grails run-app" laufe, aber wenn ich ihn als Kriegsakte in Tomcat einsetze, geht die Hölle los. Mein Token wird authentifiziert, aber ich bekomme 'springSecurityService.principal = null '. Details finden Sie in dieser [Frage] (https://stackoverflow.com/questions/43999961/springsecurityservice-principal-returns-null-when-deployed-as-a-war-in-tomcat-8). –