Monthly Archives: July 2013

Custom login view in IBM Domino

Ok, this is not new information – actually, it is so old that I had almost forgotten and had to fiddle around with some details to make it work. Therefore, I thought I might as well describe the process for everyone else to avoid wasting time on it.

The situation is that you want to customize what information you want your user to use to identify themselves. It could be an employee id or a username that the user select themselves. In a standard Domino directory you have the option to select (under the security tab in the server document):

  • More name variations with lower security
  • Fewer name variations with higher security

If you look at the design of the Server form you will see that the field HTTP_AuthView is controlling this setting. Depending on the value you select this field will hold either “($Users)” or “($LDAPCN)” (respectively). These values point at two views that control what information the user can use to identify themselves.

Now, you have a couple of options to control the login identification:

  • Use the formulas in these views to find out what information you should put into what fields in the person documents to obtain the desired identification. Many do this – and you don’t have to change any design
  • Add another option to the HTTP_AuthView field that will point logins to another view. Remember this view must be available in all directories if you are using Directory Assistance
  • Create your own view in another database and include it via Directory assistance

The last two options require the same considerations from you. I have an application that will allow users to register themselves and use the information for login. I do not want to use our primary directory or a secondary directory for this purpose. The application will know the user object (yes, a lot of Java beans here…. – but that is another story) and, therefore, there is no need to duplicate this information into a directory etc.

So I created a view in my application, named it something suitable like “UserLogin” but gave it two aliases (separated by the pipe character): “($Users) | ($LDAPCN)”. This way the server will find exactly this view independently of how the server document was configured. Of course you also have to set up Directory Assistance for this extra “directory” (which is my application) – and remember to set it to Yes for “Trusted for credentials”

Now back to the view:

  • The first column should contain the information that you want users to use to identify themselves. You can use multivalues – just mark the column to “show multiple values as separate entries”. This column must be sorted.
  • Then you need a column that has the programmatic name “FullName” – you can put whatever information you want into the field as long as you ensure it has this name – but you MUST ensure that the name is in the “canonical” format (see more in this article).
  • Finally, you need the HTTPPassword column

And that is it!

A quick note on the HTTPPassword field.

  • Calculate it when saving your user document using the formula: @Password(Password) – if your password field is called “Password” (else you will have to use the name of your own field).
  • If you want to enable the more secure internet passwords (normally configured in the Directory Profile in an ordinary Domino Directory) then you should add a field called “$SecurePassword” and set it to the value “1” (text) in your user document. This means that you will have to evaluate the @Password(..) command against the user document if you are creating/updating the information through code (which obviously you do if you use Java beans).

If you have followed along you now have your own directory service where you have full control over the way the users identify themselves – and it is fully integrated with your application.