In my bid to follow up things I've talked about in the past I want to talk about what I found out about using custom login forms with Domino. Something I was talking about late on in June.

Now, there are numerous ways of doing this and I just want to describe what I think is the best way. It's not perfect but it's the best in my eyes.

This is a game best played Domino's way. Sure, we can simply add a couple of fields to a form and POST it to a URL ending in &Login. This works but it's not ideal. What happens when a session expires or authorisation and/or authentication fail? We end up where we started, with Domino's ugly login form (I'm writing this assuming we're using session-based authentication).

I found it's best to leave the authentication to Domino. How do we do this and still get to customise our forms? Using Internet Site documents.

This is where the big problem comes in. To use custom login forms with Domino you need a separate DNS entry for each application/site. This is ok for a true website, but not so good for things like internal company applications. Let's say you have two internal apps, called Prism and Arc, on a server called Pluto, which is part of the domain rockall.com. Traditionally you might have users access them directly via URLs like http://pluto.rockall.com/prism.nsf or http://pluto/arc.nsf. To use custom login forms for each application we need an Internet Site to govern each. To do this, each will need its own DNS entry.

Obviously you need to be on good terms with the Sys. Admins to get this setup. Without them on your side you're going to be out of luck.

Once you've got DNS aliases setup you'll be able to access the apps directly via URLs like http://prism.rockall.com or simply http://arc/. There's an added bonus to this in that it makes it easy for users to remember where the apps are. If they forget the support guys just have to explain they type the name in to the browser!

So, you've got the DNS entries setup. Now you need to setup the Domino server. Here's how:

First thing to do is add a new Web Site document to the server (you need to be using a server that uses Internet Site documents in the first place!):

In this document you make all the other changes for the website, like default homepage etc.

Then we need to map a login form to this new Web Site. To do this we need to switch to that server's Domino Config (domcfg.nsf) database (create one if it's not already there). From this database create a new Sign-In Form Mapping document, like so:

There's a gotcha involved in this bit. See the field that says Web Site/Virtual Server? Well the hint for that field says: "If using Web Site configuration documents, specify the name of the Web Site this mapping applies to. Otherwise specify the Virtual Server name or IP address". From the mapping document shown above you would think this field entry would simply be "Prism". As hard as I try I can't Domino to recognise the mapping by Web Site name and have to use the DNS name instead.

This is ok until you try to map login forms for both //prism/ and //prism.rockall.com/. The web Site documents allows you to enter them both but the Mapping document will only allow one entry at a a time. So, you need two Mapping documents if you want to allow users to enter either address. Like so:

But, hey, it works. You can have a completely customised login form in your application. Because the form actually lives inside your NSF it's easy for it to share the same look, feel and layout as the rest of the application. All you need to add to it are two fields - one called username, one called password - and a "submit" button.

Obviously this is Domino and the way it works isn't quite as polished as you'd like, but at least it can be done. Any questions, let me know...