Moved the embedded default-templates into the classpath Otherwise, if the app is packaged, the templates will not be included, because the webapp-directory is ignored for builds of type "jar".
Switched to Encryptors.noOpText(), because of Illegal-key-size-issue Spring requires a key-length of 256 bits, which is not available in the JDK, because of US-export-restrictions. Because Spring Security does not enable the configuration of the key-length, the build was switched to a NoOpTextEncryptor, to circumvent this issue. The only other easy way would have been, to require the user to install the missing parts of the JDK by hand... See http://stackoverflow.com/a/17637354 for a full explanation.
Switched from InMemoryUsers- to JdbcUsersConnectionRepository with H2 This only works, if you have the full strength version of the Java Cryptographic Exctension (JCE) installed, since Spring Security is using a 256-bit key. See http://stackoverflow.com/a/17637354 for a full explanation.
Switched from the manual implemented authentication-layer to Spring Security
Refactored authorization from HomeController to UserCookieInterceptor The educationally authorization-concept now roughly resembles the behavior of Spring-Security.
Sign in users via Facebook and sign up new users automatically
Implemented a simple UserIdSource, that stores the user in a cookie This concept was borrowed from the official example "Spring Social Canvas". The idea to store the internal user-id in a cookie and later load the data of the user according to the cookie is inherent insecure and must not be used in a production environment. One simply can use Spring-Security instead - we will show how to switch in a later example. This implementation was choosen only for educational purposes, because it clarifys the design of Spring Social.
Moved Thymeleaf-templates to src/main/webapp to enable hot reload See http://juplo.de/fix-hot-reload-of-thymeleaf-templates-in-spring-bootrun/