Today I bring you a real life case and how I tackled this issue.

An important client has to consume restricted SOAP web services.  There were a few security and technology constraints to take into account, including IP filtering among others.

Because of those constraints, there is a JAVA app served by Tomcat to interface with the SOAP requests exposed as a REST API to the main app. This is good for production and staging server since their IPs are whitelisted to make web service requests, but this is still a problem when you want to develop a new feature or test something in your local environment that isn’t whitelisted and may not have a functional tomcat server running.

SSH Tunnel to the rescue!  We needed a secure way to interact with API to work on basic features and it turns out the SSH tunnel was perfect for the job.

Development Strategy (History)

The first approach we used to develop new features in local environments was mocking the response we should receive from Tomcat, develop assuming everything was correct and do an actual test in staging server. That was a slow process, specially because it has a lot of room for mistakes, having task back and forth until it’s complete.

Mocking like this has certain bad code smell and in deed it wasn’t working out well for us.

How did we enhance the process?

Since the development team has access to the staging server, http and ssh, and this server has the access to the web-service, so how can we take advantage of this? Our Tomcat listens by default on port 8080, but only on loopback interface. I thought, we need something that allow us to hit this remote server as if it was running locally, and an idea came to my mind: “tunnel“.

Yeah, a tunnel, all devs have ssh access to this server then just creating and ssh tunnel we all could use the staging Tomcat as if it was running locally.

The solution

To accomplish this idea, I created a single line shell script.

#!/bin/bash

ssh -L 8080:localhost:8080 -i ./leo.pem -N [email protected] -o StrictHostKeyChecking=no -g &

and voila!

This simple script solved the issue we had, making the develop process smoother.

Conclusion

Sometimes, a small change can bring great changes even when they are not directly related to a specific problem of domain of the project. As I show this post, there are changes we make to improve the quality of the team’s work, which can translate into a better performance.
Thanks for reading, I hope you liked it and I wish to see you in the next post.