Archive for June 2004
Since Cyrus is talking about his multi-monitor set up, I guess I want to brag, too. As many of my co-workers and friends know it, I take my workplace very seriously. I like everything running just right, positioned at the right angle and available when I need it.
I don't like cute utilities, screens savers, or backgrounds, because inevitably they take up memory and the precious milliseconds of my CPU/GPU time. I don't like applications or services running in the background if I don't need them. I work hard to eliminate items from my notification area (a.k.a. tray icons).
I generally don't like add-ins or plug-ins, because they tend to affect the performance of the application. I would rather run NUnit and Reflector as separate applications and not deal with the extra windows and behaviors of their corresponding Visual Studio add-ins. I find it easier to cluster my workspaces around a specific activity, rather than plop it all on one big pallette of a Visual Studio workspace. That is why my Visual Studio Help is firmly switched to “External“ and the Clippy of the Visual Studio — “Dynamic Help“, is banned forever from the view.
Every week, I take a little bit of time to make sure that my projects, documents, and applications are organized the way I want them. I don't believe in having an application installed and not needing to use it for more than a couple of weeks. If it's not being used — it's gone.
I like working with multiple monitors. I find that having multiple screens helps me cluster my work around specific activities and also provides enough horizon for those activites that require multiple applications running at once (such as debugging, tweaking performance, CSS, etc.). Currently, I have 4 monitors surrounding me (from left to right):
- An old Apple iBook — good enough for browser compatibility testing.
- Two monitors of my main workstation: a 17“ utility monitor. It usually hosts my Outlook and MSDN Library, and a 20“ flat panel, which is where most of the work happens.
- My mobile workstation with a 15“ screen, which is primarily used for performance monitoring or remote access. I always take this one home (just in case).
In addition to your usual CAT5 hookup, the machines are also networked with FireWire. This allows me to test networking issues and do marginal load testing, as well as some other netrickery.
All of the screens are “stitched“ together with Synergy, which is an absolute must if you have more than one machine sitting on your desk.
And finally, looking at the picture of the set up, you may notice that the laptops are held in their positions using riser doohickeys. A word of advice — before spending $130 on a laptop riser, stroll over to your neighborhood Staples store and pick up a book holder. It works just as well and costs around $10.
It is easy to turn on Windows (also known as NT) authentication on IIS:
- Check “Integrated Windows authentication”
- Uncheck the “enable anonymous access” box
- Set permissions on the file or folder that you want to be the object of authentication.
Once the authentication is turned on, anytime anonymous users access that file (or folder), they will see a login dialog box pop up, asking the users to enter their credentials before letting them to view the file. A slightly different situation will happen to those users whose browser is configured to recognize the site as part of an Intranet domain — the browser will attempt to authentication automatically, and if the authentication is successful, they will be let in without any dialog boxes popping up.
Wouldn’t it be nice if your site would not display a dialog box in either case?
- If the user can be authenticated automatically, let them in authenticated
- Otherwise, let the user in as anonymous.
This type of authentication is often needed in Intranet Web sites, where the site provides degrees of customization based on the type of the user, screening every user for authentication, but never explicitly asking for credentials. Hence the term “credentials screening”: have valid credentials? Great! Don’t have any? That’s ok, too.
The biggest challenge in this scenario is the fact that most of the “behind the scenes” work of automatic (integrated) authentication happens outside the boundaries of your client or server applications, handled completely by the browser. In other words, there is no way to control how the process happens using either server-side or client-side code.
What we need here is a function of some sort (let’s call it the screening function) that would allow us to test whether the user can be authenticated and return “true” or “false”. Also, this function will need to be called before the authentication is first attempted. These two assumptions help us outline the following principles:
- First page that the user hits must have anonymous authentication enabled
- The screening function must be contained in that first page
- In order to return a result, the screening function must somehow attempt authentication
- Authentication attempt is triggered by accessing a page which requires authentication
- Accessing a page from a client-side function can be performed using variety of methods. One of them is instantiating and using Msxml2.DOMDocument object (there are similar methods for browsers other than Internet Explorer).
After looking at the list above, the implementation of the screening function becomes crystal clear:
var dom = new ActiveXObject("Msxml2.DOMDocument");
As you can see, this function attempts to open a document, named “RequiresAuthentication.xml”. If this document has anonymous authentication disabled, the browser will automatically attempt authenticating using existing user credentials. No dialog box will be shown – if authentication fails, an exception will be thrown and the function will return “false”. Otherwise, the document will be opened successfully and the function will return “true”.
The only other issue is to make sure that this function is always called at the beginning of the user session. In ASP.NET, you can accomplish this by subscribing to an event, fired by the built-in session state management module, System.Web.SessionState.SessionStateModule. The name of the event is “Start” and the easiest way to do this is to:
- Open your application’s Global.asax.cs file
- Add your code to the body of a pre-built “Session_Start” method.
Because this method is called only once for each user session, you can write it to simply emit the HTML which contains the screening function and then end the response, in order to prevent the actual page from being displayed. Of course, your client-side code must initiate a page reload right after calling the screening function.
Another way of doing it is to develop an HTTP module, which will do the same thing and leave the Global.asax.cs file in its pristine condition. Here you can download a sample implementation of such a module.
A couple of installation instructions:
- Make “CredentialsScreening” folder a Web application
- Disable anonymous access to “RequiresAuthentication.xml” file and set its permissions according to your authentication needs.
- To test, access “Test.aspx” file with your browser.
Well, there you have it – a credentials screening solution. Hope you find it useful. If you do – drop me a note.
UPDATED 10/04/04: Referenced code was updated. For more details, look here.
For those of you interested in using the DOM Level 3 XPath implementation for Microsoft Internet Explorer 5+ in your Web applications, I created a project on SourceForge.net:
The code is released under LGPL license and provides functionally complete implementation in its first release. Next project milestones are:
- Allow passing instances of Msxml2.DOMDocument object as contextNode parameter in evaluate function
- Implement ECMAScript binding model
If you would like to participate in the project, let me know.