Archive for September, 2009


September 27th, 2009 Jeremy No comments

tripitAbout a year ago, one of my best friends introduced me to an awesome travel web application…TripIt (  The service is free and really amazing.  They provide a single resource for all of your travel information.  Simply forward your confirmation emails to them and they scrape important information and automatically import it to your itinerary.  It’s just awesome.

I used to print my confirmations just before we left, which worked fine until I lost them.  Then I would decided to save all of my emails re-forward them to myself before leaving, so I’d have them on my mobile device.  But sifting through emails while traveling is not a fun task.  Now I simply forward the confirmations as they come in, and TripIt handles the rest.  They make it easy to share information as well, so my wife can see (and modify, of course) our plans.

While TripIt is great at importing your confirmation information, they also provide an easy way to setup your own events.  This allows you to add any activities you want, complete with time, date and location.  They even integrate with Google Maps, so you can find your way without having to rely on someone else’s directions.

One of the best features of their service is the iPhone application.  Like the Trip It service, it’s amazing.  You can access your itineraries at any time, and view all of the information.  Checking into the hotel and need your confirmation number?  It’s right there.  Trying to remember how to get from your hotel to an activity?  Just use the Google Maps integration.  It’s view only, but gives you all of your travel information at your fingertips.  Plus you can use it as a reminder of your upcoming trips!

Don’t just travel, TripIt!

Categories: Travel, iPhone Tags:

Iframe Security and the onload event

September 18th, 2009 Jeremy No comments

iframeI do a substantial amount of development with a Comet application, and utilize iframes for communication.  Most web developers hear “frames” and their eyes immediately glaze over and they just look at you as if you’re nuts.  ”No, not FRAMES…IFRAMES!”  Iframes are used more than you realize, and, when used correctly, can be very beneficial to the user experience.

When using iframes, you have to be aware of their security model.  Any modern browser prevents iframes from interacting with each other unless they are from the same domain.  This is in place for obvious reasons, I wouldn’t want an advertising banner hosted in an iframe to access the parent page’s DOM or cookies.

However, there are times when you want to use iframes within your site, but pointed to different subdomains.  Perhaps you have a content iframe hosted at feeding information to your parent page accessed via  The default iframe security model will prevent interaction between them because it is limited to the fully qualified domain name as specified in the src attribute.  You can relax this to simply be the primary hostname, in this case  To do so, add a single line of javascript code to the top of your page:

document.domain = '';

That single line, added to both the parent and iframe source page, will allow them to interact without restriction.  Use at your own risk, always be aware of what is happening when your frames are interacting and avoid confusing the user.

In my Comet application, I needed to dynamically add an iframe and then tear it down when it’s processing was complete.  I could have left it hanging out in the DOM, but that’s just not clean and efficient programming.  After some research, I found this which explained exactly what was going on, and what I needed to do about it:

Thanks and kudos to Nicholas for the great and in-depth article, he addressed cross-browser compatibility and gave a very complete (and workable) solution!

Padding is invalid and cannot be removed.

September 10th, 2009 Jeremy No comments

I’ve been hunting an elusive error message for some time now.  Every now and then, one of my web applications will throw an error: “Padding is invalid and cannot be removed.”  It seemed to be random, and always linked to a web resource (AXD) file.  If I clicked the URL referenced in my Event Viewer message I would see the nasty Yellow Screen of Death.  But how in the world was it being generated?

I added more logging to my application events, and after some Googling I found this forum post:

When an application pool is recycled and the web.config doesn’t contain a machine key configuration setting, a new unique security identifier is generated to mask information regarding your web resource files.  If a request comes in after this recycle, IIS cannot decrypt it using the old security identifier and throws an error.

The solution is to generate a static machine key setting and save it in your web.config file.  Since the security identifier does not change, IIS can decrypt and serve the correct resource after an application pool recycle.

This page provides a simple way to generate the key / value pair, and even shows how to use it in your web.config.