This tip details the method I've used to prevent intranet users in a Domino environment from being prompted to enter their name and password multiple times when attempting to access a database to which they do not have permission.
Your environment
You are running IBM Lotus Domino as the back-end server for your intranet (or browser-accessible application). You have defined an ACL on a database that gives certain users rights; some users can edit, other can read, others are blocked entirely.
Incidentally, you cannot use "anonymous" as an ACL setting (except for no access and no checkboxes ticked) if you want this tip to work. In an intranet environment, it is unlikely that you would be allowing anonymous access anyway. Even if you wanted everyone in the Domino directory to have access, you would probably use a group.
I'm assuming that your server document does not allow anonymous access -- that is, Domino will always prompt your users for a name and password (see my note on using IIS below).
The problem
A user, not named explicitly or in a group in the database's ACL, who attempts access to the application will be prompted three times by Domino for a username and password until he gets an "authorization failure" message in his browser.
[IMAGE]
This is not very useful to anyone -- even if you customize the $$ReturnAuthorizationFailure form.
Why three times? Well this appears to be your browser (Internet Explorer 5+) that does this. When a password is required, it receives a 401 response from the server. The browser then prompts you for a username and password and passes that onto the server. If it gets another 401, it just repeats the process three times (duh!), presumably in the hope you'll type a correct combination of username and password. After three times, Domino gives up.
The solution
Instead of just re-prompting users for a username and password, display a page that details the problem
To continue reading for free, register below or login
To read more you must become a member of SearchDomino.com
and gives them a route to correct the error -- user-friendly and avoids help desk calls.
How to do it
First, let's get the ACL right.
Here's a screen shot of how it should look:
[IMAGE]
Now open the database up in design mode.
That's all there is to it! Users with unauthorized (default) permissions get to see a pretty "Unauthorized" page, whilst authorized users don't even know they have been redirected to the true entry page of the application!
Security questions
If you're thinking that users could bypass the security on the database by book marking (or otherwise typing in a URL that goes directly to) a form or view in the database -- it won't happen. This is because the ACL on the database will prevent them and they will get the old, boring prompt for a username and password.
A word of warning, however: access rights are accumulative. So if you assign the role of "[Unauthorized]" to a generic "everyone" group, and then give other groups actual access permissions, then all groups will get the role of [Unauthorized] assigned. Better to just leave the default ACL setting with the role and all groups not having a role assigned at all.
Incidentally, the above restriction doesn't apply if you assign individuals to the ACL; this is because an individual entry overrides all group rights, even when roles have been assigned.
Using this in an IIS environment
If you use Microsoft's IIS (part of Windows 2000) as a "front-end" for all HTTP requests, then this will work just the same -- unless you allow anonymous communication between IIS and Domino (which is not recommended anyway).
In a traditional IIS/Domino setup, IIS handles all HTTP requests (initially anyway). It then passes the requests onto Domino if there is an ".nsf" in the request. Under Domino 5.x, the HTTP task doesn't even run on Domino and all communication is via a special linking module. Under Domino 6.x, the HTTP requests are augmented with some authentication information and passed to Domino as a standard HTTP message -- albeit on a port other than 80 (possibly 81 or 9080, for example).
The advantage of using IIS is that the concept of "anonymous" users has no meaning. By virtue of logging onto your Windows PC, and hence the domain or workgroup, you are "known" to Windows. That user information is what is passed to Domino. You never get prompted to input a name and (intranet) password by Domino when using IIS.
How it works
In case you're not that familiar with the inner workings of Domino, HTML and JavaScript, here is a quick rundown of how this all works.
The user attempts to launch your Web page (in an intranet, for example). He types in, say, "http://intranet/phonebook.nsf," expecting to see the phone book application.
You, the designer, have set the phonebook.nsf application to launch a navigator called WebLaunch when instigated from a browser. Domino finds the navigator, then checks to see whether you've designed a template for it. It finds the $$NavigatorTemplate for WebLaunch form, and uses that as a presentation template to show that navigator. But, because you have not added a special field called $$NavigatorBody, it never actually displays the Navigator, just the form contents (which you have cunningly designed to be user-friendly and helpful).
The form has a computed-for-display role field on it that Domino calculates before converting it to HTML. This now allows you to interrogate the form with JavaScript and extract that value. If you detect that the user has the [Unauthorized] role assigned to him, then he gets to see the (pretty) form. Otherwise he gets transparently and silently redirected to the application's true home page/starting point.
And finally...
Did you get this tip to work? It is unclear in places. I admit I'm aiming it at seasoned Domino/Web developers -- so maybe I've presumed too much.
I'd appreciate any feedback on it, good or bad, so that I can incorporate any suggestions and refine accordingly. For example, would a sample database be of use?
Do you have comments on this tip? Let us know.
This tip was submitted to the SearchDomino.com tip exchange by member Ralph Bacon. Please let others know how useful it is via the rating scale at the end of the tip. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
