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)
Nice tip, Jake.
Question is: does Google allow for mis-spellings? :-)
[Hint: check the title of the post]
Don't know what you're on about Patrick!
Question is was Google Cache quick enough to capture the evidence ;o)
excellent tip Jake!
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
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
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?
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.
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...
Forgot to mention. Niel, I'm on 6.5.x
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)
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....
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.
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.
@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.
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??