As Steven posted earlier, if you try to display a password-protected page in SuperPreview, the program instead displays the page that appears when a site visitor tries to access the page without supplying login credentials.
I wanted to follow up Steve’s post to briefly clarify that SuperPreview does support NTLM authentication, which is commonly used by websites on corporate intranets. Pages on networks that use NTLM authentication don’t require the user to login to view the pages, instead, they rely on the site visitor’s Windows login credentials. So if your computer is on the same network as the page that relies on NTLM authentication, you should have no problems opening the page in SuperPreview. (For in depth information about NTLM, see http://msdn.microsoft.com/en-us/library/aa378749(VS.85).aspx.)
I'm Steven Schermerhorn - one of the developers that worked on the SuperPreview program provided with Expression Web 3. Ever since we released the first BETA version of SuperPreview for Internet Explorer, the Expression Web team has received a lot of constructive feedback about SuperPreview. One suggestion we frequently receive is to add support for password-protected web pages.
Currently, if you use either the BETA version or the finished version of SuperPreview to view a page that requires login credentials, instead of displaying the page you requested, SuperPreview displays whatever page normally appears when a site visitor tries to view a password-protected page without logging into the site. We weren't able to provide that support in time for this year's release, however I have one suggestion that might help you work around this: enable debug access to the website you are developing. How you or your server admin enables debug access to the website all depends on your server's configuration and I cannot document all scenarios here.
Once you've enabled debug access to your website, you can use SuperPreview to display your password-protected page by opening the URL using this syntax: http://www.example.com/default.php?user=joe , where http://www.example.com is your site's domain, and default.php is the path to your page, and joe is a valid username.
This basic debug access isn't a feature you want enabled in a live, publically accessible server environment, so you should also setup additional security for your debug environment, such as to allow requests from only a particular IP range or a specific port that isn't available outside your network. For what it's worth, I used this kind of debug environment in nearly every web application I developed in my former life as a web developer.
Hope this helps!