logo

Hacking Domino Login Form Mappings

Yesterday I had to do some server configuration. While it's not really my territory it's impossible to avoid at times and all part of being an all-round developer. That said, it doesn't help that configuring Domino is never as straight-forward as you'd expect. Here's a case in point.

Imagine I had an application called Bungle. In the Domino Directory I set up an Internet Site document to map all variants of bungle.mydomains.* so they all point to /apps/bungle.nsf. It would look like this:

Note that using one Internet Site document I've covered all the domains.

Now imagine that I've added a funky-looking login form to bungle.nsf and I want to make sure any login attempts at bungle.whatever.* point to this form. To do this I need to create a "Sign In" Form Mapping in the domcfg.nsf database. Something like this:

Notice that the "Web Site/Virtual Server" is listed as BUNGLE. This is the same value as we gave to the name of the Internet Site document earlier. This is how you'd expect it work, no? Well, it doesn't. I've tried everything and have always had this problem with domcfg.nsg mappings to Internet Site document by name. Notice I've even left spaces out of the name in an attempt to work it all out. It just does not work.

The popup help for this field in the mapping document says (emphasis my own):

If using Web Site configuration documents, specify the name of the Web Site this mapping applies to. Otherwise specify the Virtual Server name or the IP address.

So, by naming the mapping BUNGLE it should have worked? Is it me or does this popup help not help at all. Web Site? Are they the same as Internet Sites? Virtual Servers? What are they? What about FQDNs — are they allowed?

After hacking about I managed to work it out. You can in fact add the FQDN to this field, but, for each domain, you need to create a new mapping. The reason for this is simple — in the Internet Site document the field to record the host names is multi-value, while, in the mapping document, it isn't.

So, we need to create one mapping for each FQDN, like so:

So there you have it. That's how to map login forms to more than one domain which points to the same application. I was tempted to try and change the LF_IP field to multi-value to see if that worked. My guess is it would. Maybe if Domino ever went open source that could be my first fix.

This might look like an excuse for me to have a dig at Domino, which it is. Moreover it's to help out you guys in the future and people having the same problem who might Google it. So add this to your mental bookmarks of problems solved here at codestore.net ;o)

Comments

  1. Nice tip, Jake.

    Question is: does Google allow for mis-spellings? :-)

    [Hint: check the title of the post]

    • avatar
    • Jake
    • Wed 17 May 2006 05:37 AM

    Don't know what you're on about Patrick!

    Question is was Google Cache quick enough to capture the evidence ;o)

  2. excellent tip Jake!

    • avatar
    • Niel
    • Wed 17 May 2006 11:41 AM

    Maybe you can tell me if you have a solution for a problem I ran into. I had a request for the login form to remember the user id of the last login. So I set a cookie with the value of @Username and I put a default formula in the UserName field on the login form using @GetHTTPHeader("Cookie") to retrieve the value.

    It worked as plan until I started using &login in my urls. If I had domain/names.nsf the login form worked, if I used domain/names.nsf?Open&login the login form was not used, instead a default yellow and white login form was used.

    Email me if you would like to see sample URLs.

    Steps to reproduce:

    Add @GetHTTPHeader("Cookie") as the default value to UserName field

    Open a URL using &login

    • avatar
    • Jake
    • Wed 17 May 2006 12:03 PM

    Niel. How did you set the cookie originally? Maybe that's the cause of the problem.

    I've just managed to get @GetHTTPHeader("Cookie") to work in a Login for mapped to from domcfg.nsf

    • avatar
    • Niel
    • Wed 17 May 2006 01:32 PM

    I reduced the problem just to using @GetHTTPHeader("Cookie"), regardless if there were cookies set or not. It might be the version of Domino I'm using. The server is stuck @ 6.0.x. What version are you using?

    • avatar
    • Mark Vincenzes
    • Wed 17 May 2006 04:37 PM

    Jake wrote: "I was tempted to try and change the LF_IP field to multi-value to see if that worked. My guess is it would."

    I dont think that would work. When the web server looks in domcfg.nsf to find the alternate form, it uses a sorted view with LF_IP as the index column and the server name from the url as the key. If you change the data entry form to allow a list, the value in the view column will be the entire list and you won't get a match.

    • avatar
    • Jake
    • Wed 17 May 2006 04:54 PM

    Mark. Are you sure? Which view do you mean? And what do you mean by index and key columns? Same thing?

    The only view I can see it called $LoginForms and it's a simple one-column view that's sorted on the LF_IP field. If I change the column to show the multi-values as separate entries and make the field multi-value, how will the server know any different?

    I'm curious now and going to give this a go. I'll report back...

    • avatar
    • Jake
    • Wed 17 May 2006 04:55 PM

    Forgot to mention. Niel, I'm on 6.5.x

    • avatar
    • Jake
    • Wed 17 May 2006 05:05 PM

    Ok. I just tried the theory out and it works.

    I hate to say I told you so Mark, but, err, I told you so ;o)

  3. To me the confusion in this blog was that one wanted to apply a rule base logic to the mappings. I don't think there is a 1 to 1 correlation with these documents.

    I have always perceived that the mappings are tield to FQDN entries. I have had the wildcard or asterix work in the subdomain, but now for the suffix.

    My observation is how developer logic is being applied to Administration. The trade off is how fast can the server respond when there is logic to test for a specific condition than doing an equality test (is this applicable to this domain).

    here is what I would havedone differently. I would have made an entry for subdomain.domain.com as an internet site document. I would then have all the other subdomain.domain.suffixes that I want to go to redirect to the initial document created. This would result in only needing only one mapping document matching the initial internet site document.

    the trade off to the above is that no matter what internet suffix the web user enters, the web browser will report back the .com suffix. But I see I as a small trade off when the reality is that you are having the identical site for all the domain.suffixes.

    Hope it is helpful....

    • avatar
    • Mark Vincenzes
    • Wed 17 May 2006 06:05 PM

    I was using "index" as the thing you look in and "key" as the thing you are looking for.

    And yes, setting the column to show one view entry for each of the values would do the trick. I was wondering if you could do that, but I didn't take the time to look.

    The two changes sound like they would do what you want.

    But maybe Patrick Corey has a better approach. With his way there would be only one place (the redirect rules) to change if you wanted to add (or remove) one of the web sites.

    • avatar
    • Mark Vincenzes
    • Thu 18 May 2006 09:51 AM

    I was looking at this a bit more and found out that redirect rules don't apply to server names, just the path components (and in some cases the query string) part of the URL.

  4. @Mark and others,

    I written a blog entry sharing how to do my suggestion. It does work and I have a working example with a specific domain. Note it will work for subdomains as well, but example was more straight forward using domains. The entry is titled: "Redirecting Web Domains". It had URL links which is hard to post here as well as a little long for a comment post.

    Feel free to respond and respond.

    • avatar
    • Sameer
    • Fri 16 Jun 2006 01:33 PM

    Scenario:

    An HTTP request for a web application having Default and Anonymous access as No Access is sent,

    a login page is opened over HTTPS, configured on DOMCFG.nsf,

    successfull login, request redirected with HTTP protocol to the web application.

    possible?? HOW??

Your Comments

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


About This Page

Written by Jake Howlett on Wed 17 May 2006

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 »

Elsewhere

Here are the external links posted on the same day.

More links are available in the archive »

More Content