Spring Boot Validation in Kotlin with @field

Parker Drake — Fri, 29 Jan 2021 05:05:32 +0000

Recently I found myself needing to validate fields in a Spring Boot controller written in Kotlin. Here's the code I ended up with:

@Controller
@RequestMapping("api/sample")
class SampleController {
    @PostMapping
    fun post (@Valid @RequestBody request: SampleType){
        return ResponseEntity.ok().build()
    }
}

data class SampleType(@field:NotBlank info: String)

The key is the @field in the data class. Without that, Kotlin will apply validation to the constructor parameters by default. This makes sense when you see it, but is less obvious when you're wading through your 10th Java based tutorial on Spring validation.

Hope this helps!

Debugging Spring Security

Parker Drake — Thu, 21 Jan 2021 17:53:57 +0000

Spring Security is hard to debug and hard to test. Make your life easier with significantly better log output by using debug = true in the EnableWebSecurity annotation:

@EnableWebSecurity(debug = true)
public class CustomConfig extends WebSecurityConfigurerAdapter {
    // your config here
}

Don't use this in production!

CORS Hides Real Bugs

Parker Drake — Thu, 14 Jan 2021 23:01:30 +0000

Before You Scroll

If you're here because you have a CORS error and you think it's hiding your real problem, run this command:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security --user-data-dir=~/temp/chrome

This will start up a Chrome instance with web security turned off, which gets CORS errors out of the way leaving you free to debug your response (assuming the CORS error itself isn't your problem).

For the bug in this blog, we spent about 4 hours debugging before we ran the above command, and then had the issue fixed an hour later.

The Background

Recently my pair and I implemented a feature to process some data with a long running GraphQL mutation (about 2 minutes to return a response on a production size data set). There are better ways to do this without such a long-running request, but this particular action happens rarely enough we just went with this approach and plan to revisit it later.

The Bug

On our development machines, everything would run just fine, but in our higher environments, we'd get this lovely error in the browser console:

Access to fetch at '[OUR API]' from origin '[OUR FRONTEND]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Some other interesting things we noticed:

There were no errors in the server logs.
The data processing was actually happening just fine, but the response was buggy.
We'd get this message exactly 1 minute after we fired the request, every time.

The Fix

Turns out, because of the long running request, we were bumping up against 2 different timeout limits in our stack, one at our ingress controller, and one at our DNS. It makes sense that we couldn't replicate this locally, since in our dev environments there is neither ingress nor DNS. Tweaking those limits was all we needed. Once we launched into a CORS free world using this command: