Upgraded Spring Boot from 1.3.1 to 1.5.14

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".

Added a fixed dependency for the mysql-jdbc-connector to the build

Renamed the pom-properties and enabled the docker-build

Switched H2 to server-mode and made the console available in the app

Added a fix to repair the login-redirect when using the Chrome-browser

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.

Simplified the configuration of Spring-Security: defaults are not disabled

Redirect to originally requested page after sign-in

Switched from the manual implemented authentication-layer to Spring Security

Refactored instantiation of helper classes: @Service instead of manual

Enabled logging of HTTP-requests and -responses

Also switched to the performant and mature HttpClient-library from Apache.

Authentication through the canvas-attribute signed_request

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.

Make Spring-Boot's implicit autoconfiguration explicit

Moved Thymeleaf-templates to src/main/webapp to enable hot reload

See http://juplo.de/fix-hot-reload-of-thymeleaf-templates-in-spring-bootrun/

Added a second page to proof, that the connection is persisted

Authenticate against Facebook

Based on the "Getting Started"-example:
http://spring.io/guides/gs/accessing-facebook/