Spring Security VS Flyway

Spring security has long had great OAuth2.0 support from both the server and client elements. Recently spring security added support for the private_key_jwt client authentication method as part of the authorization code grant flow. Spring Security GitHub ref

To be fair there were quite some unexpected surprises in the past with Spring and Kotlin (e.g. the Cachable annotation did not work with suspend functions, not all Spring security annotations were supported with coroutines), but most of them were ironed out already.

They recently updated all the examples in the javadocs if you wanna bump your Spring Security version to 5.7.3 (see here). Otherwise the reference docs all reflect the non-deprecated approach that uses SecurityFilterChain and supporting beans.

Spring Security 5.7

Since Spring Security 5.7.0-M2 the use of WebSecurityConfigurerAdapter was deprecated (link to GitHub - https://github.com/spring-projects/spring-security/issues/10822) to move to component-based security configuration.

When i start the flow, no proxy is used and even the WebClient is not used to get access token. And i get a timeout exception for that. The same issue was discussed in Github: https://github.com/spring-projects/spring-security/issues/8966

You can extract (and validate) the JWT token into the Principal by implementing the getPreAuthenticatedPrincipal method, and map the claims to user details by providing through a custom implementation of AuthenticationUserDetailsService.

Or, maybe simpler, is to create your own filter and add it after the SecurityContextPersistenceFilter. Here, just recreate the authentication token from the database, which is what token based authentication does (token based authentication has to preauthenticated authentication from the token for the actual user authentication with the user details).

The session logs show that the application loads configurations and establishes a connection with a PostgreSQL database. This involves initializing a HikariCP connection pool and Flyway for database migrations. The logs confirm that the database schema validation and migration checks were successful. The startup of the Jetty HTTP server follows, and the server becomes operational and ready to accept requests on the specified port.

Also RedGate, but Flyway has some reasons to recommend it over RedGate Deploy depending on your DBAs/workflows: https://flywaydb.org/

(Though I don't think it is "complete" or "perfect", either.)

EF Migrations are in a really good place now if you like/don't mind C# as a language (and you can easily embed SQL inside the C#, too, but there are benefits to being able to also run high level C# code). With today's tooling you can package your migration "runner application" as a single deployable executable for most platforms. You can build the executable once and run it in all your environments. (The same tool that updates your QA and Staging updates your Prod, testably running the same migrations.) Given the single executable deployable I might even consider using it for projects not themselves written in C#.

There is a bit of tooling needed but is already around. For Java for example I had very good experience with a combination of flyway [1] for migrations, testcontainers [2] for making integration tests as easy as unit tests and querydsl [3] for a query and mapping layer.

[1] https://github.com/flyway/flyway

[2] https://java.testcontainers.org/modules/databases/postgres/

[3] https://github.com/querydsl/querydsl

When software starts using a database, it's advisable to have version control, just as we have Github to control our source code. This is all to be sure about what was executed for that specific version. For Java and Spring boot, we have the Flyway framework that aims to resolve this situation, free of charge.

If you're looking for tools, like https://www.liquibase.com/ or https://flywaydb.org/, which are database-state-based schema migration toolkits - it might be relatively straightforward to build similar ones using Databricks SQL drivers.

Honestly I kind of wish there was a Lukas Eder database migration library. Call it whatever jooq-migration. At least I would have more insight of what is going on (<-- seriously look at the commit history).

This is a 4th option, which should play nice with ArgoCD. The following example runs flyway as a k8s job. The desired migration changes are recorded as files within the chart. This helm chart can be integrated with your application (Using hooks to determine when the migration job is run) or run manually.

By using an opinionated framework within the app/service (like Flyway, Migrate, Diesel, etc). Schema migrations happen on app/service start-up.

Depending on the language or platform there are libraries you can use to manage this, such as Prisma on node and Flyway for Java/JVM.

It's probably overkill but I've used github plus flyway at a couple places in the past which is pretty nice tool for tracking changes to a variety of db's, it's also very helpful if you ever need to replicate a db in a new region/environment.