Vision

@echo off
rem http://www.pipeboost.com
net stop iisadmin

REM Setup IIsCompressionScheme for deflate
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcCompressionDll %windir%\system32\inetsrv\gzip.dll
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcCreateFlags 0
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcDoDynamicCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcDoOnDemandCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcDoStaticCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcDynamicCompressionLevel 9
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcFileExtensions “htm” “html” “txt” “js” “xml” “css”
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcOnDemandCompLevel 9
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcPriority 1
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions “asp” “dll” “exe” “aspx” “asbx” “ashx” “axd”

REM Setup IIsCompressionScheme for GZip
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcCompressionDll %windir%\system32\inetsrv\gzip.dll
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcCreateFlags 1
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcDoDynamicCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcDoOnDemandCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcDoStaticCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcDynamicCompressionLevel 9
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcFileExtensions “htm” “html” “txt” “js” “xml” “css”
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcOnDemandCompLevel 9
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcPriority 1
cscript c:\inetpub\adminscripts\adsutil.vbs set W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions “asp” “dll” “exe” “aspx” “asbx” “ashx” “axd”

REM Setup IIsCompressionSchemes parameters
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcCacheControlHeader max-age=86400
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcCompressionBufferSize 102400
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcCompressionDirectory %windir%\”IIS Temporary Compressed Files”
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcDoDiskSpaceLimiting FALSE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcDoDynamicCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcDoOnDemandCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcDoStaticCompression TRUE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcExpiresHeader “Wed, 01 Jan 1997 12:00:00 GMT”
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcFilesDeletedPerDiskFree 256
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcIoBufferSize 102400
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcMaxDiskSpaceUsage 0
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcMaxQueueLength 1000
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcMinFileSizeForComp 1
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcNoCompressionForHttp10 FALSE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcNoCompressionForProxies FALSE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcNoCompressionForRange FALSE
cscript c:\inetpub\adminscripts\adsutil.vbs set W3SVC/Filters/Compression/Parameters/HcSendCacheHeaders TRUE

net start w3svc

pause

Public Function TableToHtml(ByVal t As System.Web.UI.WebControls.Table) As String

Dim Builder As New StringBuilderDim Writer As New System.IO.StringWriter(Builder)

Dim HTMLWriter As New Html32TextWriter(Writer, ” “)t.RenderControl(HTMLWriter)

Return Builder.ToStringEnd Function

@echo off
net stop iisadmin

REM Setup WebService IIsCompressionScheme
cscript C:\Inetpub\AdminScripts\adsutil.vbs set w3Svc/829054140/root/DoDynamicCompression TRUE
cscript C:\Inetpub\AdminScripts\adsutil.vbs set w3Svc/829054140/root/DoStaticCompression TRUE

net start w3svc

pause

Ask how to control the back button on a forum and you’ll be quickly lectured how
interfering with the browser’s history is evil and that you’re a bad person for
wanting to do it. You’ll then be told it’s impossible. But, guess what? Both
groups are wrong!

Almost everyone who asks how to control the back button is trying to make pages
accessed while a user was logged in, inaccessible once a user has logged out.
A good example of this is a banking page. If you log in, transfer a few funds,
then log out, no one should be able to hit the back button a few time and see
what you were doing.

So wanting to control the back button isn’t an evil request. There are many,
MANY legitimate uses for wanting to do so.

window.onbeforeunload

Around Internet Explorer version 4.0, Microsoft decided there needed to be
a way for secure banking and e-commerce sites to have some control over the
session history. They did this with the javascript event onbeforeunload,
a very funky little method that is called right before the browser navigates
to a new URL.

There are two things that happen when you set an onbeforeunload event. One, you
can give the user a chance to re-think the decision to leave the page by spawning
a “yes/no” dialog box; and two, just having an onbeforeunload event will cause the
browser to never cache the page: This means that the page will always be
rendered exactly as if the user was hitting it for the very first time.

onbeforeunload is a method of window (the global/root javascript object).
You set up the event pretty much like any other event.

window.onbeforeunload = function () {
   // stuff do do before the window is unloaded here.
}

Are you really, really sure you want to leave my glorious page?

What makes onbeforeunload quirky is that if you return ANYTHING at
all in your event handler it will pop up a confirmation alert box asking the
user if he or she is REALLY sure they want to leave the page. The exact text is:

Are you sure you want to navigate away from this page?

Click OK to continue, or Cancel to stay on the current page.

This dialog box will appear if you return ANYTHING in your function. return null,
return false, return true, return “some text” will all bring up the confirmation
dialog box.

You can insert your own explanatory text BETWEEN those two lines by including
a string on the return statement. For instance:

window.onbeforeunload = function () {
   return "You have not saved your document yet.  If you continue, your work will not be saved."
}

…will change the alert box to read…

Are you sure you want to navigate away from this page?

You have not saved your document yet.  If you continue, your work will not be saved.

Click OK to continue, or Cancel to stay on the current page.

As you can see, the starting and ending lines stay the same, your text
is inserted into the middle.

If the user clicks ok, the onunload event will trigger and the browser will
navigate to the new page. If the user clicks cancel the user will be returned
to the current page where he or she left off.

You can see an example of this by clicking this link. If you click OK
this timestamp should change (Timestamp: 1180247244687). If you click cancel, the timestamp should remain the same.

If you don’t want a confirmation dialog box, simply do not include a return statement
in your function. Just close the curly braces ( } ) naturally without
a return statement.

window.onbeforeunload = function () {
   // This fucntion does nothing.  It won't spawn a confirmation dialog
   // But it will ensure that the page is not cached by the browser.
}

Detecting When The User Has Clicked Cancel

One of the things you may want to do is to be notified when the user clicks
cancel, aborting a page unload. Unfortunately there’s no way to be immediately
notified. The best you can do is to set a unique global variable in your onbeforeunload
event and then look to see if that variable has been set in other functions. There is
no way to get an immediate notification that the user has aborted a page unload.

The example code I used above to do an example of an onbeforeunload dialog
is as follows:

var _isset=0;

function demo() {
   window.onbeforeunload = function () {
      if (_isset==0) {
         _isset=1;  // This will only be seen elsewhere if the user cancels.
         return "This is a demonstration, you won't leave the page whichever option you select.";
      }
   }
   _isset=0;
   window.location.reload();
   return false;
}

This code defines a global variabled named _isset, and then initializes it to zero.
In our onbeforeunload event the variable is checked and if it’s set to one,
no unload dialog box will appear. The only way _isset could ever be one is if
the user previously aborted a page unload.

But as you can see this method won’t help you if you need to be immediately notified
that that the user has finished dealing with the confirmation box. You can detect when
it appears on the screen but there’s no way to know when the user has finished interacting
with it if the user clicked cancel (if the user clicked OK, then of course the unload
event will have been tripped).

Truly Dynamic Pages

Just having an unbeforeunload event handler — regardless of whether or not
it actually does anything, regardless of whether or not you spawn a dialog
box or not, even if the entire function declaration consists entirely of just { }
– just defining an event handler will prevent the page from being cached –
ever.

As a matter of fact, even if you allow page caching, the page will be not be
cached. Having an onbeforeunload event means the page will be re-built
every single time it is accessed. Javascripts will re-run, server-side scripts
will be re-run, the page will be built as if the user was hitting it for the
very first time, even if the user got to the page just by hitting the back or forward button.

Some security considerations.

Although onbeforeunload ensures the page will be fresh each time,
you may still want to issue meta commands and server-side headers to control
the cache — just to be sure the browser doesn’t store a copy on the sly. You
can do this with server side headers (php examples here)…

header("Cache-Control: no-cache, must-revalidate");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Pragma: no-cache");

And with browser meta tags (not as reliable but it never hurts to try).

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="01 Jan 1970 00:00:00 GMT">
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

Now in the what were they thinking department, you want to put cache
control meta tags in a <head> section below the
<body> tag. Microsoft has a good writeup
on why this is so. Just mark this up as yet another browser idiosyncrasy to contend with.

Good cache-control will reduce the chance that someone can go through the physical
cache on the user’s machine and extract sensitive information.

Logged out? No page for you!

Since onbeforeunload event pages are not cached and are rebuilt each
time the user access it, it means your server side script can determine if the
user is logged in or not and serve the appropriate pages. You can even see if
the session has timed out and redirect the user to the login page.

Shutdown Nicely

In addition to disabling page caching, onbeforeunload gives you a
chance to nicely handle unload events. For instance you could submit the current
form data, marked as incomplete and rebuild it if the user comes back to the page.
Another good example of this is handling session
logging. By incorporating a small synchronous AJAX call you can log when the user left
the page, giving you an idea of how long each user is staying on the page.
If you don’t set up a confirmation dialog, this activity would be completely
transparent to the user. Here’s a simple template you can use
to do just that.

window.onbeforeunload = function() {
   // This template uses no error checking, it's just concept code to be
   // expanded on.

   // Create a new XMLHttpRequest object
   var AJAX=new XMLHttpRequest();  

   // Handle ready state changes ( ignore them until readyState = 4 )
   AJAX.onreadystatechange= function() { if (AJAX.readyState!=4) return false; }

   // we're passing false so this is a syncronous request.
   // The script will stall until the document has been loaded.
   // the open statement depends on a global variable titled _userID.
   AJAX.open("GET", 'http://someurl.com/endsession.php?id='+_userID, false);
   AJAX.send(null);
}

The choice to use a synchronous call is deliberate and important. A synchronous
request will stall the browser until it gets a reply back from the server. If we
were to initiate an asynchronous request the request would be made but the browser
would continue the unload event and chances are the browser would never get the
response back from the server. So in your unload events you need to keep AJAX
synchronous.

Browser Check

onbeforeunload was introduced with Internet Explorer 4, so it has pretty
good support. A lot of users surf without javascript however so if you decide
to use onbeforeunload to help manage your session you’ll need to make
extensive use of <noscript></noscript> and dynamic HTML generation through
javascript to nudge users into enabling javascript, at least for your pages. On
the server side you’ll also need to do some browser checking to ensure the browser
supports onbeforeunload.

You can’t change history

The history object, for good reason, has been put into a security lockdown.
You can’t use it to modify the history. You can however have some small and
very imperfect control over the current url.

location.replace(url)

Using the command above you can replace the current page with the url of your
choice, this replaces the current URL in the user’s history as well. If
the page is VERY sensitive you can use this when the user opts to log out.
Firefox will let you use location.replace(URL) right before the return statement
in an onbeforeunload event. That is, if you do a location.replace and
then spawn a confirmation box, the current page will be altered.

window.onbeforeunload = function () {
   location.replace('http://www.google.com');
   return "This session is expired and the history altered.";
}

It’s kind of clunky in that if the user opts to cancel he’ll be on the replacement
page instead of the original page, and the replacement page will actually be loaded
as he ponders the confirmation dialog. If he selects OK however he’ll navigate
forward normally and if he hits the back button he’ll be taken to the replacement
URL.

It’s important to note than in Internet Explorer 6 that you can not use
a location method at all in any unload event, so the trick of modifying the history of the current page
will work (kinda) only in Firefox. It’s not something you can depend on.

If you MUST control History

If you absolutely must be able to clear out the history, then spawn a new
window (without a location line) and when the user is done, close the window.
The URLs will still be in the browser’s history list ( cntrl-h ), but the
session’s backward and forward button list will have been destroyed.

Conclusion

Really, manipulation of the browser’s history is unnecessary as long as you
are dynamically generating your web pages and you use onbeforeunload events
to ensure the page will always be fresh. If the page is being dynamically generated
then even if someone goes through the history list and clicks on one of your
session URLs, it won’t really matter because the page will be rebuilt from scratch
meaning you can check to see if the session has expired and if the user is logged in
or not. If the check is failed, you simply re-direct the browser to a login page.

And there you go! Everything you need to know to ensure secure sessions, stay
secure and private, no matter who sits down at the browser an hour later.