​​ http://docs.spring.io/spring-security/site/docs/4.2.0.RELEASE/reference/htmlsingle/#authorize-requests​​

37.5 Spring MVC and CSRF Integration

37.5.1 Automatic Token Inclusion

Spring Security will automatically ​​include the CSRF Token​​​ within forms that use the ​​Spring MVC form tag​​. For example, the following JSP:

<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
  xmlns:c="http://java.sun.com/jsp/jstl/core"
  xmlns:form="http://www.springframework.org/tags/form" version="2.0">
  <jsp:directive.page language="java" contentType="text/html" />
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <!-- ... -->

  <c:url var="logoutUrl" value="/logout"/>
  <form:form action="${logoutUrl}"
    method="post">
  <input type="submit"
    value="Log out" />
  <input type="hidden"
    name="${_csrf.parameterName}"
    value="${_csrf.token}"/>
  </form:form>

  <!-- ... -->
</html>
</jsp:root>

Will output HTML that is similar to the following:

<!-- ... -->

<form action="/context/logout" method="post">
<input type="submit" value="Log out"/>
<input type="hidden" name="_csrf" value="f81d4fae-7dec-11d0-a765-00a0c91e6bf6"/>
</form>

<!-- ... -->

37.5.2 Resolving the CsrfToken

Spring Security provides ​​CsrfTokenArgumentResolver​​​ which can automatically resolve the current ​​CsrfToken​​​ for Spring MVC arguments. By using ​​@EnableWebSecurity​​ you will automatically have this added to your Spring MVC configuration. If you use XML based configuraiton, you must add this yourself.

Once ​​CsrfTokenArgumentResolver​​​ is properly configured, you can expose the ​​CsrfToken​​ to your static HTML based application.

@RestController
public class CsrfController {

  @RequestMapping("/csrf")
  public CsrfToken csrf(CsrfToken token) {
    return token;
  }
}

It is important to keep the ​​CsrfToken​​​ a secret from other domains. This means if you are using ​​Cross Origin Sharing (CORS)​​, you should NOT expose the ​​CsrfToken​​to any external domains.

 

@EnableWebMvcSecurity


As of Spring Security 4.0, ​​@EnableWebMvcSecurity​​​ is deprecated. The replacement is ​​@EnableWebSecurity​​ which will determine adding the Spring MVC features based upon the classpath.

 

​​http://docs.spring.io/spring-security/site/docs/current/reference/html/mvc.html​​

75.2 Initialize a database using Hibernate

You can set ​​spring.jpa.hibernate.ddl-auto​​​ explicitly and the standard Hibernate property values are ​​none​​​, ​​validate​​​, ​​update​​​, ​​create​​​, ​​create-drop​​​. Spring Boot chooses a default value for you based on whether it thinks your database is embedded (default ​​create-drop​​​) or not (default ​​none​​​). An embedded database is detected by looking at the ​​Connection​​​ type: ​​hsqldb​​​, ​​h2​​​ and ​​derby​​​ are embedded, the rest are not. Be careful when switching from in-memory to a ‘real’ database that you don’t make assumptions about the existence of the tables and data in the new platform. You either have to set ​​ddl-auto​​ explicitly, or use one of the other mechanisms to initialize the database.


You can output the schema creation by enabling the ​​org.hibernate.SQL​​​ logger. This is done for you automatically if you enable the ​​debug mode​​.

In addition, a file named ​​import.sql​​ in the root of the classpath will be executed on startup if Hibernate creates the schema from scratch (that is if the ​​ddl-auto​​property is set to ​​create​​ or ​​create-drop​​). This can be useful for demos and for testing if you are careful, but probably not something you want to be on the classpath in production. It is a Hibernate feature

75.3 Initialize a database using Spring JDBC

Spring JDBC has a ​​DataSource​​ initializer feature. Spring Boot enables it by default and loads SQL from the standard locations ​​schema.sql​​ and ​​data.sql​​ (in the root of the classpath). In addition Spring Boot will load the ​​schema-${platform}.sql​​​ and ​​data-${platform}.sql​​​ files (if present), where ​​platform​​​ is the value of ​​spring.datasource.platform​​​, e.g. you might choose to set it to the vendor name of the database (​​hsqldb​​​, ​​h2​​​, ​​oracle​​​, ​​mysql​​​, ​​postgresql​​​ etc.). Spring Boot enables the fail-fast feature of the Spring JDBC initializer by default, so if the scripts cause exceptions the application will fail to start. The script locations can be changed by setting ​​spring.datasource.schema​​​ and ​​spring.datasource.data​​​, and neither location will be processed if ​​spring.datasource.initialize=false​​.

To disable the fail-fast you can set ​​spring.datasource.continue-on-error=true​​. This can be useful once an application has matured and been deployed a few times, since the scripts can act as ‘poor man’s migrations’ — inserts that fail mean that the data is already there, so there would be no need to prevent the application from running, for instance.

If you want to use the ​​schema.sql​​​ initialization in a JPA app (with Hibernate) then ​​ddl-auto=create-drop​​​ will lead to errors if Hibernate tries to create the same tables. To avoid those errors set ​​ddl-auto​​​ explicitly to "" (preferable) or "none". Whether or not you use ​​ddl-auto=create-drop​​​ you can always use ​​data.sql​​ to initialize new data.

​​https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html#howto-execute-flyway-database-migrations-on-startup​​

75.5.1 Execute Flyway database migrations on startup

To automatically run Flyway database migrations on startup, add the ​​org.flywaydb:flyway-core​​ to your classpath.

The migrations are scripts in the form ​​V<VERSION>__<NAME>.sql​​​ (with ​​<VERSION>​​​ an underscore-separated version, e.g. ‘1’ or ‘2_1’). By default they live in a folder​​classpath:db/migration​​​ but you can modify that using ​​flyway.locations​​​ (a list). See the Flyway class from flyway-core for details of available settings like schemas etc. In addition Spring Boot provides a small set of properties in ​​FlywayProperties​​​ that can be used to disable the migrations, or switch off the location checking. Spring Boot will call ​​Flyway.migrate()​​​ to perform the database migration. If you would like more control, provide a ​​@Bean​​​ that implements​​FlywayMigrationStrategy​​.


If you want to make use of ​​Flyway callbacks​​​, those scripts should also live in the ​​classpath:db/migration​​ folder.

By default Flyway will autowire the (​​@Primary​​​) ​​DataSource​​​ in your context and use that for migrations. If you like to use a different ​​DataSource​​​ you can create one and mark its ​​@Bean​​​ as ​​@FlywayDataSource​​​ - if you do that remember to create another one and mark it as ​​@Primary​​​ if you want two data sources. Or you can use Flyway’s native ​​DataSource​​​ by setting ​​flyway.[url,user,password]​​ in external properties.

There is a ​​Flyway sample​​ so you can see how to set things up.

​​https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html#howto-execute-flyway-database-migrations-on-startup​​