Beware of firewalls

I'm always weary whenever I see firewalls in deployment architecture. It almost always spell problems. Problems that one will never realize during user acceptance tests. Simply because a user acceptance test environment will never mirror production environment. Hardware firewalls are not cheap.

Luckily, most firewall problems I had seen always boil down to the same thing.

Closing of idle connections.

Most applications would use connection pools, to reuse existing opened connections, for better performance. It can be for database connections, ldap connections, or any other kind.

However, a problem occurs if a connection is allowed to lie idle over a period of time.

Especially if the pool idle connection timeout is longer than the firewall idle connection timeout.

What usually happens is this:

1. Firewall idle connection timeout is set to 30 mins.
2. Database idle connection timeout is set to 60 mins.
3. Database connection timeout is set to 10 mins.
4. Connection is opened from client to server.
5. Connection is left idle for 40 mins, and the firewall closes the idle connection.
6. Client application retrieves the closed idle connection from pool, and sends a database query.
7. Client application blocks for a 10 mins before timing out, because the connection is already closed.

There are three ways to resolve this problem.

1. Set the connection to 'ping' the server while idle from time to time. This could be a select 1 query while idle.
2. Set the database pool idle timeout to be a value lower than the firewall idle connection timeout value (if you are allowed to)
3. This is the more common approach, which is to set the firewall idle connection timeout value to a value higher than the database pool idle timeout. This sounds exactly the same as the 2nd way, but people are usually more inclined to modify firewall settings than application settings.

Creating social network accounts for corporations

It's getting very common nowadays to have an account on the social network for your corporation. It could be a need to have a Facebook or Twitter presence, or creating a Facebook application for your corporation.

But regardless of the nature of the presence and account, it is undeniable that you really want the account to be owned by the corporation, not an individual employee.

Imagine that today you asked an employee to create a Facebook application or fan page. He creates it with his personal Facebook account. His personal account is thus the owner of the Facebook application or fan page. You could have multiple admins or developers, but there can be only one owner, and as far as I know, it is non-transferable. Some year later he leaves. And there goes your owner of the Facebook application or fan page. I do not think it is possible to revoke his access to the application or fan page, because he is the owner.

That sure sounds like bad news to me.

The correct approach here should be to create a new social network account for the corporation. Have all operations and management done via that account. Make it the owner of all media and content on the social network. In fact, create a corporate email address for this too. Like social@mycorporation.com.

And then have the corporation own the account. Control access to that account, and if passwords are shared, change the passwords when an employee who knows the password leaves. But really avoid too many people knowing the password. Assign additional admins or developers on social media projects with delegated capabilities.

As social media become more and more predominant, it is critical that companies develop a social media policy, and be aware and protective of their social media presence.