Po skonfigurowaniu Spring Security 3.2 _csrf.token
nie jest powiązany z żądaniem ani obiektem sesji.
Oto konfiguracja zabezpieczeń wiosny:
<http pattern="/login.jsp" security="none"/>
<http>
<intercept-url pattern="/**" access="ROLE_USER"/>
<form-login login-page="/login.jsp"
authentication-failure-url="/login.jsp?error=1"
default-target-url="/index.jsp"/>
<logout/>
<csrf />
</http>
<authentication-manager>
<authentication-provider>
<user-service>
<user name="test" password="test" authorities="ROLE_USER/>
</user-service>
</authentication-provider>
</authentication-manager>
Plik login.jsp
<form name="f" action="${contextPath}/j_spring_security_check" method="post" >
<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}" />
<button id="ingresarButton"
name="submit"
type="submit"
class="right"
style="margin-right: 10px;">Ingresar</button>
<span>
<label for="usuario">Usuario :</label>
<input type="text" name="j_username" id="u" class="" value=''/>
</span>
<span>
<label for="clave">Contraseña :</label>
<input type="password"
name="j_password"
id="p"
class=""
onfocus="vc_psfocus = 1;"
value="">
</span>
</form>
I renderuje następny html:
<input type="hidden" name="" value="" />
Wynikiem jest stan HTTP 403:
Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'.
UPDATE Po pewnym debugowaniu obiekt żądania wychodzi dobrze z DelegatingFilterProxy, ale w linii 469 CoyoteAdapter wykonuje request.recycle (); która usuwa wszystkie atrybuty ...
Testuję w Tomcat 6.0.36, 7.0.50 z JDK 1.7.
Nie zrozumiałem tego zachowania, a raczej byłoby to możliwe, gdyby ktoś wskazał mi kierunek wojny z próbkami aplikacji ze Spring Security 3.2, który działa z CSRF.
spring-security.xml
) z Spring 4.0.0 RELEASE (GA), Spring Security 3.2.0 RELEASE (GA) (chociaż jest zintegrowany z Struts 2.3.16. Nie dałem mu spróbuj z samym Spring MVC). Jednak kończy się to niepowodzeniem, gdy żądanie jest wieloczęściowe, aby przesłać pliki o stanie 403. Trudno mi znaleźć rozwiązanie tego problemu.