ING Life Insurance site now live!

November 15, 2008 – 11:18 am

Well, after many months of work, our ING Life Insurance site is now live!  While I’m partial to my own work, I do believe this site has a fantastic combination of content, tools, and actual steps to follow as you research your options for life insurance.

I also happen to think this site is unique on the internet compared to all other life insurance sites:

  • Provides a wealth of information about life insurance
  • Is sponsored and developed by a real, trusted financial institution who actually offers the product in question (i.e. not a brokerage)
  • Allows users to find out exactly how much life insurance costs, and…
  • Allows users to get started with actually buying life insurance

It’s not every day you get to work on something that is unique on the web.


Troubleshooting: Rule #1

November 15, 2008 – 11:10 am

Despite nearly 10 years of web development, I still often make mistakes.  Bugs creep in.  So, in addition to my developer hat, I’ve also had to assume the hat of troubleshooter/tester.  Over the years, I’ve developed an affinity for various tools and method for finding bugs in my code.  Of course, a debugger is tool #1..

But along with that, my #1 rule for troubleshooting is:

If something is not working like it “should”, your assumptions are wrong.

I can’t tell you how many times I’ve stared at the screen (or watched other developers stare at the screen) saying “this shouldn’t be happening.”  Well, there is no point in wasting energy being frustrated that the stupid computer is doing something it’s not supposed to.  The fact is, almost every time, the computer (including the computer’s software) is doing exactly what it is supposed to, even exactly what YOU told it to do.

So, the first thing to do, is to re-check your assumptions.  Is your configuration file right?  Is the code you just wrote even being run (enter the debugger)?


Row-level Security with NHibernate and .NET

October 29, 2008 – 8:58 pm

Ever wondered about how to apply row-level security to your data?  In other words, is the data for one of your customers/clients/accounts potentially right next to data for another customer? If so, your data may be exposed if your web pages use query string parameters or form data to run queries.  For example, say you have a page that does this?

/pages/view.aspx?id=24

If so, what happens when someone manually types (or POSTs) a URL like so:

/pages/view.aspx?id=25

Do you even check that they have access?  Is your method of checking cumbersome, subject to remembering to do it?  Ever wish you had a way to force developers to check for access?  Well, here’s a quick and easy method for doing just such a thing.

First, create an interface that each of your data objects will implement:

public interface ISecureDataObject
{
bool EnsureAccess(ref T owner);
}

Then, implement it in our Data class:

 public class MyData : ISecureDataObject
{
public bool EnsureAccess(ref int accountId)
{
return this.AccountId == accountId;
}
}

Then, wherever you lookup the object, you can check to make sure they have access.

MyData m = sess.Get(myDataId);
m.EnsureAccess((int)Session["AccountId"]);

You can even enhance it more, so that an exception is automatically thrown.

public void EnsureAccess(object o, int accountId)
{
if (o is ISecureDataObject)
{
if (!((ISecureDataObject)o).EnsureAccess(ref accountId))
{
throw new DataAccessException("Your account (" + accountId + ") does not have access to this object. ");
}
}
else
{
throw new Exception("Programmer error - the object you are checking does not implement the requested security access method.");
}
}

Sloppy for testing low bandwidth

August 28, 2008 – 8:45 am

Here’s a neat tool I found recently for profiling websites and simulating a certain connection speed.

We wanted to see how someone’s experience would be on one of our soon to be broadly released heavy Flash sites if the user had only 512 Kbps of bandwidth. Needless to say, it wasn’t great… but acceptable.