Spring MVC PreAuthorize and private/final methods

Spring MVC has nice feature for adding security controls to Controller methods via @PreAuthorize annotation, but there’s an interesting problem that might occur when those methods are mistakenly marked as private or final.

Spring uses CGLib proxy to add calls to authorization logic declared in @PreAuthorize before calling actual controller method, but CGLib fails to process private or final methods, producing error like this in console:

2016-11-28 17:19:14.186 INFO 97079 --- [ main] o.s.aop.framework.CglibAopProxy : Unable to proxy method [public final java.util.Map com.package.controller.MyController.someMethod(javax.servlet.http.HttpServletResponse)] because it is final: All calls to this method via a proxy will NOT be routed to the target instance.

Well, so far so good – nothing special happens, all is more/less expected.

The problem though is that among most console output produced by Spring MVC yet another INFO log line rarely gets noticed. So what actually happens with those private/final methods of SpringMVC controller? Here weird stuff begins.

Say you’re writing a controller method that has a @PreAuthorize added to it, and accidentally copy-paste in a return type with final predicate before it, thus making your method final. You miss the log line in console because it’s just INFO among many other similar lines. And then… all autowired or otherwise injected fields of a controller are somehow null when calling only that particular method. But we know that in Spring MVC every controller is a singleton, so how is this even possible?

The issue appears to be that we’re actually calling methods on a CGLib proxy, that can’t pass them down to actual controller class instance. But proxy itself looks just like the controller class instance, except all fields that were supposed to be injected by Spring are null. A weird looking symptom which does not intuitively lead us to the cause of the problem.

But once one encounters this issue, I bet one remembers well next time what it is a symptom of.

P.S. I’ve encountered this issue with final method, but seems other people had same issue with private methods.

Posted in MVC

Installing Cisco AnyConnect VPN on Ubuntu 16.04

Oracle, Unix and the world at large

I was struggling setting up a new VPN to connect to my servers at the office as vpnsetup.sh was failing

# ./vpnsetup.sh 
Installing Cisco AnyConnect Secure Mobility Client...
Extracting installation files to /tmp/vpn.0Zgby3/vpninst625702875.tgz...
Unarchiving installation files to /tmp/vpn.0Zgby3...
Starting Cisco AnyConnect Secure Mobility Client Agent...
Failed to start vpnagentd.service: Unit vpnagentd.service not found.

I found a bunch of articles on the internet saying that this was due to missing libraries so started with the first batch of recommendations…

# apt install -y lib32z1 lib32ncurses5

This still didn’t work.

So I tried the next one, which was to also install the network-manager-openconnect package and reload the daemons

# apt install network-manager-openconnect

# systemctl daemon-reload


# ./vpnsetup.sh Installing Cisco AnyConnect Secure Mobility Client... Removing previous installation... mv: cannot stat '/opt/cisco/vpn/*.log': No such file or directory Extracting installation files to /tmp/vpn.yUyv15/vpninst922924093.tgz... Unarchiving installation files to /tmp/vpn.yUyv15... Starting Cisco AnyConnect Secure Mobility Client…

View original post 13 more words

Docker with xHyve on Mac – access stopped container files

I had a problem with Docker on Mac OS X – nowadays it comes with xHyve VM instead of VirtualBox, and the VM uses cow2 format for it’s disk image, so it wasn’t clear how can one access files in /var/lib/docker on the VM.

Why does one even have to access the files? Well, there can be number of reasons. In my case it was Mosquitto container where Mosquitto MQTT broker is a PID 1 process, and when it’s not running – the container isn’t running either. So while changing a config file for Mosquitto I had to do some experimenting, which caused Mosquitto to fail on startup due to bad configuration.

As you can probably guess, it wasn’t possible to fix Mosquitto config otherwise than via /var/lib/docker, because I could not start the container anymore. So it was either this, or start from scratch with new container.

Anyhow, I did not find any working way to mount cow2 image, but I have found a solution on Docker forums to get terminal into xHyve VM when docker was started:

screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty

The username is root with no password.

Thanks to Rohinton Kazak for posting that answer.