Tolsdorf.NET

I 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 data.mydomain.com feeding information to your parent page accessed via www.mydomain.com.  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 mydomain.com.  To do so, add a single line of javascript code to the top of your page:

document.domain = 'mydomain.com';

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:

• http://www.nczonline.net/blog/2009/09/15/iframes-onload-and-documentdomain/

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!

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:

• http://stackoverflow.com/questions/617782/is-this-an-attempt-to-break-my-asp-net-sites-security/617940#617940

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.

• http://www.orcsweb.com/articles/aspnetmachinekey.aspx

When it comes to development, I typically treat 3rd party tools and libraries like the plague.  Sure they might something cool, but if you account for the time debugging their implementation you could sometimes write them yourself.  Or worse yet, you cannot upgrade the parent application without breaking the 3rd party add-on!  When it comes to mission critical applications (database, web server, etc), I champion native, fully supported solutions only.

Much like any piece of code, there are occasional exceptions.  Recently I wanted to add tooltip functionality to several web screens.  I wanted something beyond the native browser tooltips, those always feel junky and unreliable.  In the process of writing a small library, I stumbled on to Walter Zorn’s tooltip library.  I scanned the documentation, then paused.  On the surface it looked great, it had the tweaks I really wanted: cross-browser support, delay for opening and closing and HTML support.  But would it really work?

Implementation was simple enough, download the javascript files, reference them and call a single function.  Ok, I like simplicity, I like the way he passes parameters to his functions and the script files were small enough.  So I decided to give it a try…and was very impressed!  Sure enough, it worked as advertised the first time.  I tested in a few browsers (FF 3 and 3.5, IE 7 and 8 and Chrome) and the tooltips worked and looked great.  They even have drop shadows, a very nice touch.

So I must say that this library is an exception to my rule, I am very impressed and plan to use it more throughout my sites.  Tooltips are a small but elegant addition to a quality site, they provide necessary but unobtrusive help to the user.  This library gives you the ability to add them quickly and easily…download and try it today.  He has several other javascript libraries, I hope to find time to experiment with them sometime soon.  Highly recommended!