Ab dem 22. September 2017 ist die Version von Spring Security 4.2.3, daher tritt dieses Problem nicht auf: Schweiß :.
** Nachtrag 2018/9/12: ** ** In Spring Security 4.2.5, 5.0.2 wird die Reihenfolge von Filteranwendung → Header-Schreiben erneut geändert, sodass das gleiche Problem auftritt. Darüber hinaus gibt es in Problem einen Follow-up-Bericht, der in diesem Artikel behandelt wird. Es sieht aus wie der Unterschied zwischen Puffergröße und Festschreibungsgröße. ** ** **
Es scheint jedoch, dass Spring Security erschüttert, welche Spezifikation korrekt ist. Seien Sie daher beim Upgrade vorsichtig.
Beschreiben Sie bei der Ausgabe mit TERASOLUNA das Header-Element von Spring Security in spring-security.xml.
Im folgenden Beispiel werden die standardmäßig angewendeten Header deaktiviert und nur die Komponenten registriert, die nur die Header "Cache-Control" und "X-Content-Type-Options" ausgeben.
spring-security.xml
<sec:http>
<sec:headers defaults-disabled="true">
<sec:cache-control />
<sec:content-type-options />
</sec:headers>
Die Klasse, die den Header schreibt, ist "org.springframework.security.web.header.HeaderWriterFilter", die von der "doFilterInternal" -Methode verarbeitet wird. Die Implementierung in Spring Security 4.1.0 RC1 wurde jedoch geändert.
Verwandte Ausgabe: SEC-2728: Only write cache related headers if no other cache headers found #2953
↓ 4.0.1. DoFilterInternal Methode bei RELEASE
HeaderWriterFilter.java
@Override
protected void doFilterInternal(HttpServletRequest request,
HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
for (HeaderWriter factory : headerWriters) {
factory.writeHeaders(request, response);
}
filterChain.doFilter(request, response);
}
↓ 4.1.0 doFilterInternal Methode bei RC1
HeaderWriterFilter.java
@Override
protected void doFilterInternal(HttpServletRequest request,
HttpServletResponse response, FilterChain filterChain)
throws ServletException, IOException {
HeaderWriterResponse headerWriterResponse = new HeaderWriterResponse(request,
response, this.headerWriters);
try {
filterChain.doFilter(request, headerWriterResponse);
}
finally {
headerWriterResponse.writeHeaders();
}
}
In 4.0.1 erfolgt die Verarbeitung in der Reihenfolge des Schreibens von Headern → Filteranwendung, in 4.1.0 jedoch in der Reihenfolge von Filteranwendung → Schreiben von Headern.
Bei Verwendung von try-finally wird der Header auch dann geschrieben, wenn im Filteranwendungsprozess eine Ausnahme auftritt. Wenn der http-Stream jedoch im Filteranwendungsprozess geleert wird, wird er, selbst wenn der Header geschrieben wird, auf die Clientseite geschrieben. Wird nicht gesendet. (Ich konnte nicht genau herausfinden, was das Problem war, als ich das Problem mit dem Fehlerbericht anrief: ängstlich :) Im Folgenden sind die Zielprobleme aufgeführt. Weitere Informationen finden Sie hier.
Lassen Sie uns die Version von Spring Security erhöhen: smiley:
Wenn Sie die Version nicht einfach aktualisieren können, ersetzen Sie den "HeaderWriterFilter".
In der Fehlerberichtausgabe von ↑ lautet die Änderung von HeaderWriterFilter Zurücksetzen, also`HeaderWriterFriterF Es ist in Ordnung, wenn Sie verwenden.
Wenn Sie einen anderen "HeaderWriterFilter" als Spring Security 4.1 in "com.neriudon.sample.filter" platzieren und ihn "CustomizedHeaderWriterFilter" nennen, sieht dieser wie folgt aus.
spring-security.xml
<bean id="secureCacheControlHeadersWriter"
class="org.springframework.security.web.header.writers.DelegatingRequestMatcherHeaderWriter">
<constructor-arg>
<bean
class="org.springframework.security.web.util.matcher.AntPathRequestMatcher">
<constructor-arg value="/**" />
</bean>
</constructor-arg>
<constructor-arg>
<bean
class="org.springframework.security.web.header.writers.CacheControlHeadersWriter" />
</constructor-arg>
</bean>
<bean id="customizedHeaderWriterFilter" class="com.neriudon.sample.filter.CustomizedHeaderWriterFilter">
<constructor-arg ref="secureCacheControlHeadersWriter" />
</bean>
<sec:http>
<sec:headers disabled="true" />
<sec:custom-filter position="HEADERS_FILTER"
ref="customizedHeaderWriterFilter" />
Der Punkt ist
<sec:headers disabled="true" />
<sec:custom-filter position="HEADERS_FILTER"
ref="customizedHeaderWriterFilter" />
Es ist der Teil von.
Sie können position verwenden, um es durch Ihren eigenen Filter zu ersetzen, aber Sie müssen headers disabled =" true " setzen, da dies mit vorhandenen Filtern in Konflikt steht.
Daher wird der Header angegeben, der an den zu ersetzenden Filter ausgegeben werden soll. Dieser Teil wird in den TERASOLUNA-Richtlinien aus Ausgabe des Sicherheitsheaders für jedes Anforderungsmuster zitiert. Hat.
Als ich die Version von TERASOLUNA anhob, wurde der Header nicht mehr ausgegeben, also: frowning2: Es gibt einen Kommentar, dass das Verhalten in Tomcat / JBoss sogar in der Fehlerbericht-Ausgabe anders ist, aber ... Es ist tief: enttäuscht_relieved:
Recommended Posts