Improve csrf login caveats

Add a suggestion to retrieve a fresh csrf token right before the
form submission in order to avoid problems with invalid csrf tokens
due session timeouts.

Fixes gh-3925

docs/manual/src/docs/asciidoc/index.adoc

@@ -3459,6 +3459,8 @@ As previously mentioned, this is not as secure as using a session, but in many c
 ==== Logging In
 In order to protect against http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests[forging log in requests] the log in form should be protected against CSRF attacks too. Since the `CsrfToken` is stored in HttpSession, this means an HttpSession will be created as soon as `CsrfToken` token attribute is accessed. While this sounds bad in a RESTful / stateless architecture the reality is that state is necessary to implement practical security. Without state, we have nothing we can do if a token is compromised. Practically speaking, the CSRF token is quite small in size and should have a negligible impact on our architecture.
 
+A common technique to protect the log in form is by using a javascript function to obtain a valid CSRF token before the form submission. By doing this, there is no need to think about session timeouts (discussed in the previous section) because the session is created right before the form submission (assuming that <<csrf-cookie,CookieCsrfTokenRepository>> isn't configured instead), so the user can stay on the login page and submit the username/password when he wants. In order to achieve this, you can take advantadge of the `CsrfTokenArgumentResolver` provided by Spring Security and expose an endpoint like it's described on <<mvc-csrf-resolver,here>>.
+
 
 [[csrf-logout]]
 ==== Logging Out