Frustrations with Spring Security and Baeldung Actually Helped

So I was playing around with a little Spring Security and trying to piece together a registration/signup page.  I didn’t really want to deal with authenticating users or any of the pieces that might get in my way in that regard so I attempted to just allow my requests (GETs and POSTs) directly through to my registration page Controller which would handle both.   Seems easy enough, right?

I went about setting up my class annotated with @EnableWebSecurity and extended the WebSecurityConfigurerAdapter class.  I overrided (overrode?) the “configure” method of this class and put a “permitAll()” on an antMatch of “/registration” – which the Controller was mapped to handle and proceeded to “GET” the form for registration.

The “configure” method looked like this:

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/resources/**", "/registration", "/css/**").permitAll()
.anyRequest().authenticated()
.and()
.formLogin()
.loginPage("/login")
.permitAll()
.and()
.logout()
.permitAll();

}

The GET request was going through to the controller and returning the view, but the POST action from the form contained in the registration page was receiving a 302 and was redirecting to the non-existent login page.

I searched around to find out what was going on since I’m not well-versed in Spring Security.  I looked into what exactly “permitAll” was doing and how it compared to  trying to disable autoconfigured filters and things like that.  I came upon this Baeldung article which said:

This is achieved without disabling the security filters – these still run, so any Spring Security related functionality will still be available.

This made me wonder…  what are the security filters that are magically put in place by the Spring Security setup by default..?

I then found this very helpful Baeldung article which allowed me to get a look at what filters were working and what they were doing.

You change the declaration of your Security Config class like so:

@EnableWebSecurity(debug = true)

and set your logging level so:

logging.level.org.springframework.security.web.FilterChainProxy=DEBUG

New Hosting Machine

I host this little web site at home on an Ubuntu Linux machine.  Just for kicks, I recently bought a new, more beefy machine and migrated everything over from the old machine to the new one.

I use LetsEncrypt certificates to provide HTTPs on this site.  (They’re FREE)  When I was copying files from the old machine to the new machine, I just copied the entire /etc/letsencrypt directory and went on my merry way.  Everything ran fine and Apache was happily running with the certificates at their specified locations.

Yesterday, however, my certificates expired.  I tried to run “certbot” to renew my certificates but I received a strange error.  First, however, I was warned that my certificates in /etc/letsencrypt/live were not symbolic links.  It was true; I had simply copied the certs from wherever they were to the “live” directory.  So, I just put the certs somewhere else and made a symbolic link to them.  That’s when the strange error started happening when I tried to renew the certificates.  The error was something like this:

TypeError:  not supported between instances of 'NoneType' and 'NoneType'

Thankfully, certbot is written in Python so I could try to take a look at the code.  After looking it over a bit, I figured out that it’s probably best to put the certificate in the “archive” directory and link to it from “live”.  There were 14 PEM files in the archive directory, and the last was named “cert14.pem”, so I just linked the cert.pem in the live directory to that file.  I did this for all four files used to support TLS and when I reran certbot…BINGO!  All the certs had been renewed and the site was back in working order.

Long Time Since Update

It’s been a long time since I’ve written here. During this time, I got a new job and have been working on an Android application for Soft-Pak. I’m also working on the back end. Basically, the Mobile-Pak project has been in my hands for close to a year now.  I had never worked on an Android application prior to this job, so it’s been a bit of a steep learning curve.  My feet have also been held to the fire several times because Mobile-Pak is critical to the operations of the customers.  If Mobile-Pak isn’t running, trash trucks don’t go out.   That’s bad.

Using REST Assured for Testing

I decided to start testing my Dropwizard RESTful interface by using REST Assured.  After poking around a little bit to figure out how to test my service as deployed, I arrived at using REST Assured after seeing it referenced in quite a few places.

After I figured out the basics of using it with its “given/when/then” syntax and setting headers, I wondered how to keep from setting the headers – including Content-Type – on each request/response.  I found out that to do this you must work with a RequestSpecBuilder.

I also found out a little bit about JSONPath while working on this aspect of my project.

Investigating Dropwizard

I was over at /r/java scanning the posts when I ran into a question about Java microservices and what people are using.  I saw two comments mentioning Dropwizard so… thought I’d take a look at it.

It’s similar to Spring Boot, but perhaps with a more heavy emphasis on simply banging out RESTful web services.  Dropwizard uses Jetty under the covers to handle all of the socket stuff and whatever other kind of servlet functionality it might need.

Within the Reddit thread, there’s also quite a bit of talk about Docker and how people are using it.  Dropwizard has introduced me to the idea of “fat jars” which I’d never heard of previously – which seem in a way to be a competitor to using Docker to package up your application.  Basically, a fat jar is one giant jar which includes all of the class files from every dependency of your application.  Here’s a web resource on the topic from 2012.