My initial frameset needed to support anonymous users, though, so I couldn't just append "&login" to each of the URLs. That would force everyone to login, which was not my intention. Instead, I copied my default frameset, renamed it "WhoAmI" (just for fun), and had my "Login" link open this new frameset and authenticate by using this URL: ../WhoAmI?OpenFrameset&login.

That still won't resolve the issue of the right frame using cached credentials, so I added "&login" to the URL of the page that would load in the right frame. I did this in the Frameset designer so that the browser would be forced to use higher credentials than anonymous in the right frame as soon as the frameset loads. This way, if I had any action buttons in the View or Page that loaded, they would show up appropriately, and I wouldn't have to recode all my links in the left frame to have "&login" in them.

Conclusion
I hope this article has helped shed a little light on the issue of caching credentials. It's one of those situations where it helps to look under the surface to see exactly how the Web browser handles the pages we want served. That way, people who visit our Web sites will see just what we intend them to, and that's good for everybody.

For more than 20 years, David Gewirtz, the author of Where Have All The Emails Gone? and The Flexible Enterprise, has analyzed current, historical, and emerging issues relating to technology, competitiveness, and policy. David is the Editor-in-Chief of the ZATZ magazines, is the Cyberterrorism Advisor for the International Association for Counterterrorism and Security Professionals, and is a member of the instructional faculty at the University of California, Berkeley extension. He can be reached at david@zatz.com.