Після налаштування Spring Security 3.2 _csrf.token
не пов'язаний із запитом або об'єктом сеансу.
Це конфігурація безпеки навесні:
<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>
Файл 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>
І він відображає наступний html:
<input type="hidden" name="" value="" />
Результат - 403 статус HTTP:
Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'.
ОНОВЛЕННЯ Після деякої налагодження, об'єкт запиту виходить із тонкої форми DelegatingFilterProxy, але в рядку 469 CoyoteAdapter він виконує request.recycle (); що стирає всі атрибути ...
Я тестую в Tomcat 6.0.36, 7.0.50 з JDK 1.7.
Я не розумів такої поведінки, аніж, можливо, якщо хтось спрямує мене у бік якоїсь зразкової війни додатків із Spring Security 3.2, яка працює з CSRF.
spring-security.xml
) з Spring 4.0.0 RELEASE (GA), Spring Security 3.2.0 RELEASE (GA) (хоча він інтегрований із Struts 2.3.16. Я не дав йому спробуйте лише з Spring MVC). Однак це не вдається, коли запит є багаточастинним для завантаження файлів із статусом 403. Я намагаюся знайти рішення для нього.