logo

Modifying The $$LoginForm in DomCFG.nsf For Faster Logins

A large amount of any developer's time is spent testing. Well, hopefully that's the case. It's true for me at least.

Testing is tedious and boring. Anything that can make it less of a hassle is a godsend. Hopefully this tip will help you out if you do a lot of testing where you need to continuously login and out as different users. I know it's helped me no end since I started doing it.

I don't know how I managed to remain sane before I switched to this technique.

The Problem

When you setup a new Domino server, enable session-based authentication and then create the domcfg.nsf database you will see this screen when you're required to login:

DominoLogin

Apart from looking butt-ugly there's not much wrong with this per se. It works. I wouldn't ever use it on a live site but it normally suffices for the development server.

The problem is when you're doing intensive testing and logging in/out every couple of minutes. You soon get tired of having to type in the name/password of the test user every time.

This is made all the worse by the fact that the default login form that comes with domcfg.nsf has autocomplete="off" in the username and password fields. The means that b won't offer to remember passwords for the form.

You're forced to type the name and password of the user every time even if you use a browser which is able to store them.

The Solution

One solution is to remove the autocomplete attribute from the fields on the $$LoginUserForm and let your browser store the passwords.

However, even with the browser auto-completing the fields it still requires keyboard use and takes longer than it needs to. What I'm after is the quickest way possible to switch from one user to another.

Before I describe my solution let's make the following assumptions:

  1. You test on a machine given over primarily to development and testing alone.
  2. You "own" the server and can make any changes you like to its configuration.
  3. It's not generally accessed by "normal" users.
  4. The NAB on the sever contains a set of test users, all of whom have the same HTTP password.
  5. These test users' credentials can't be used to access any sensitive date elsewhere.

If most of the above are true then why not hard code the usernames and password in to the login form?! Here's what the form could look like:

 ScreenShot003

All you need to do here is change the dropdown to the user you want to login as and press "sign in" (password has already been pre-filled at the server).

Although I lived with this for a couple of days and it was a massive improvement over the original form I still felt it could be simpler and quicker to use. What I came up with is possibly as simple as a multi-user login form could get:

 

ScreenShot004

 

When required to login all you have to do is press the button with the name of the required user on it. Couldn't get much simpler than that. No need to worry about the password as it's pre-filled and hidden using type="hidden".

How Does It Work

This technique makes use of the fact that the humble submit button is nothing more than an input field, which you can give a name and which is submitted with the form as a name/value pair, just like an ordinary field. In this case I've called the button "Username" and removed the actual "username" field from the login form.

The other trick used is that you can have multiple inputs of the same name. When there are lotus of submit buttons with the same name it's the one pressed which sends its value (the text displayed on the button) to the server as the field value. Make sense? The HTML looks something like this:

<td><input type="submit" name="UserName" value="Jordan Quinones"></td>
<td><input type="submit" name="UserName" value="Keith Moore"></td>
<td><input type="submit" name="UserName" value="Margarito Yarbrough"></td>

Simple! To create the HTML for these buttons all we need is a simple Computed Value on the form. The formula for which is along the lines of:

names:=@Trim(@Sort(
"Administrator":"Deandre Hoyt":"Caitlin Hudson":"Allie Jarrett":"Charlie Jacobson":
"Reyna McCarthy":"Eliza Mayo":"Dick Mayfield":"Keith Moore":
"Jordan Quinones":"Alexander Welch":"Margarito Yarbrough":"":""
));

@Implode("<input type=\"submit\" name=\"UserName\" value=\""+names+"\">"; @NewLine);

 

In the form I showed you I've used a formula to put them in a nicely-laid-out table though. Download the demo database to see how.

As you can see I've used a hard-coded set of usernames taken at random from the "fakenames" NAB, which I use on most test servers and which contains 40,000 users all with the password of "password".

If your test server's NAB is more normal and just has a handful of "Test One", "Test Two" users then you could even have the formula above do a lookup to get all the usernames for you. For me a handful of users normally suffices.

Download

If you want to use this method in your dev environment then download the modified version of domcfg.nsf now and copy the $$LoginForm over. What will you do with al the time you save...

Comments

  1. "lotus of submit buttons" - LOL!

    But seriously: Thanks!

    • avatar
    • Jake Howlett
    • Wed 30 Jul 2008 03:28 AM

    Haha. A unintentional typo that I will leave in there for effect. Ties in well with Monday's post. Imagine typing a there were "lotus of bugs in it". Maybe that should be the collective noun for errors - A Lotus of Bugs.

  2. Nice...I just create some shortcuts in a folder on my desktop that log me in as the user I want to test as.....

    http://<Host>/names.nsf?Login=<Login Form name>&username=<username>&password=<password>&redirectto=<URL you want>

    Works like a charm and I never see the login form.

  3. Hi Jake

    Nice idea. You do not have to modify domcfg.nsf. Create your own database, copy the $$LoginUserForm to this database (and perhaps call it something else, e.g. TestLoginFom). Then you add a Sign In Form Mapping document in domcfg.nsf where you point to your new login form.

    I think this will only work if you have enabled "Load Internet configurations from Server\Internet Sites documents" in the server document - but there are only very few reasons why you would not want to do this anyway.

    With this solution you can upgrade your Domino server as often as you want without having to deploy your changes to domcfg.nsf every time.

    .... and you can have different login forms for different websites (that is what we use it for).

    John

    • avatar
    • Mischa
    • Wed 30 Jul 2008 04:37 AM

    In Firefox 2/3, it's possible to store and use credentials despite the autocomplete=off settings

    1. Create a bookmarklet to activate the autocomplete flag. You may have to adapt the field names for other sites.

    Name: Enable Password Saving

    Location: javascript:var%20flds=document.getElementsByName('username');flds[0].setAttribute('autocomplete','on');
    flds=document.getElementsByName('password');flds[0].setAttribute('autocomplete','on')

    2. Go to the application login screen

    3. Click the bookmark 'Enable Password Saving' to activate autocomplete.

    4. Enter username/password

    5. Submitting it and Firefox will offer remembering these credentials.

    6. The next time you open the login site, Firefox offers the credentials after you type the first letter of username even if the autocomplete is off.

    7. To change the stored password, you have to execute the Enable Password Saving before entering the new information.

    The bookmarklet works in MSIE7 as well but for some reason IE never auto-completes even autocomplete is turned on in application itself. May be a hidden security setting.

    Please post back if you can make it work in MSIE7.

    • avatar
    • Jake Howlett
    • Wed 30 Jul 2008 04:40 AM

    Hi John. You don't need "Load Internet configurations from Server\Internet Sites documents" enabled to use a custom login form mapping document in domcfg.nsf. You only need to use Internet Sites documents if you want a different login form for the different sub/domains hosted on the server.

    Where you put the form is down to the given scenario I guess, but, as you say, it doesn't have to be in domcfg.nsf...

  4. Hey, I am new in Lotus iNotes. I'm trying to get work Authentication Form ($$LoginForm) in order to my users use a Form to access their webmail.

    How can I call the LoginForm from the web.....please help with this.

  5. Someone could help me how to edit the file in $ $ LoginForm DomCFG.nsf place where I think to edit the html?

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


About This Page

Written by Jake Howlett on Wed 30 Jul 2008

Share This Page

# ( ) '

Comments

The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content