Elegance vs Utility – How to address this problem as a software developer?

I came across an issue in one of my code today.

A rest client I wrote was throwing error when consuming a third party rest service.

It was working well and suddenly started throwing exceptions. I debugged and found out that the issue was due to a security fix I recently added. Fixing security vulnerabilities is a top priority for organizations nowadays and so this cannot be skipped.

What I had done is sanitize the incoming requests.

My requests were coming as a Map of objects. It also contained sub maps. And one of the values in the sub map was an integer type.

Something like this :

{
  "request":{

              "name": "vijay",
               "age": 30
            }

}

As you see age is an integer with the value 30.

I sanitized the above input using an internal API which had in turn used ESAPI. The problem was it was converting integers to double!

Why would a security fixing code convert an integer to double . How is a double more secure than an integer?

It was a bug in the API.

To fix this , I could do any of the below :

1. Use a different API to sanitize input
2. Inform the team owning the internal API to fix the bug
3. Add code in my REST client to handle this specific use case.

Doing any of the first two would be elegant and ideal.

But the problems are:

The internal API was already a standard and used across teams. Using a different might raise questions in code review.

Informing the team owning the API team to fix the issue might take a long time. First I need to find which team owns it , communicate with them over a meeting and then wait for the bug to get fixed (provided they agree it as a bug)

So time consuming for such a small change!

I took the third approach instead.

It is inelegant. It defers loose coupling. I am tying a specific use case to be handled in a generic rest client.

But in this scenario the advantages over weigh the disadvantages. I shouldn’t waste a huge time for a petty issue.

So having decided on the third approach , I will let the security API convert integers to double values.

I will post process it.

The security API was appending “.0” to all integer values (Eg) 5 got converted to 5.0)

And I thought how best I could do it . These approaches came to my mind:

1. Just for the particular attribute ( “age” in the above example) , write an if condition. Convert the integer to double and save it back to the request object.
2. Be more generic. For any input with a double type , convert it into an integer.
3. Have a whitelist of attributes which need to be post processed and convert them to integers.

None of the approaches were good enough because:

The first approach makes the code too tightly coupled with the use case. Why should a generic rest client which just calls another REST service and returns the response do this processing.

The second approach might introduce new bugs. What if there is a attribute which is a genuine double data type. It should not be converted into an integer.

The third approach is better. Still I need to maintain a list of values somewhere.

I instead took the below approach . It is still inelegant but serves the purpose .

I iterated the input and looked for double data types. If the double value ended with “.0” , I converted to an integer.

It worked!

Yes it is not elegant but is it worth trying to spend huge amount of time over this small issue?

May be die hard designers won’t agree.

But I feel , your code cannot be always loosely coupled given constraints like this .

In those scenarios it is better to find the best option among the other alternatives.

As a programmer we often come across this :

There are more than one way of finding a solution to a problem . And you have to find the best solution , given the constraints you have.