From 69306a8b467b57b0edca48d87129dea0c2ccd41c Mon Sep 17 00:00:00 2001 From: Johnny Lim Date: Thu, 14 Jul 2016 02:37:26 +0900 Subject: [PATCH] Fix typo (#3968) Fixes typo `advantadge` --- docs/manual/src/docs/asciidoc/index.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/manual/src/docs/asciidoc/index.adoc b/docs/manual/src/docs/asciidoc/index.adoc index 1407a2a6b1..10e45da2a0 100644 --- a/docs/manual/src/docs/asciidoc/index.adoc +++ b/docs/manual/src/docs/asciidoc/index.adoc @@ -3469,7 +3469,7 @@ 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 <> 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 <>. +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 <> 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 advantage of the `CsrfTokenArgumentResolver` provided by Spring Security and expose an endpoint like it's described on <>. [[csrf-logout]] @@ -9941,4 +9941,4 @@ Provides Spring Security's JSP tag implementations. include::{include-dir}/faq.adoc[] -include::{include-dir}/migrating.adoc[] \ No newline at end of file +include::{include-dir}/migrating.adoc[]