A plea for help
The trouble with hosting a site like this is that you have to constantly resist temptation. The temptation is to use it as your very own forum. Every time you come across a problem you can write a blog and sit back and wait. I think they call it the LazyWeb. So far, I think I've been pretty good at not doing this. However, I am in a situation at the moment. I have until Friday to tell a client whether a piece of work is possible or not. They want to register web visitors in a secondary address book so that they can then return at anytime and log back in to the application. However, they really don't want this list of people to be visible to internal staff. Mainly, they don't want the new external names to appear in the type-ahead list when creating internal memos. Kind of like IBM staff not wanting to see all of the LDD Forum users in their Send To list in a Memo.
So far, I have posted the problem twice. Once in the R5 forum and once in the R6 forum (as they are currently using 6.0.1).
I thought it would be an easy one. Whereas there's been some good feedback to the posts I am yet to find a suitable solution. Can any of you guys help? Surely there's an easy answer! I hate having to ask. Not only from a point of pride but also as I think it's an abuse of my position. But, as you know, I am out of work at the moment and I need to rely on the odd piece of work to keep me going.
Skip to the 
You can subscribe to an individual
Hi Jake,
You can setup directory catalog and in the advanced tab in the configuration doc you can specify a selection formula. According to 'Domino 5 Administration Help' this will do it for you.
Thanks Vitor. Sounds promising. I will give a go and report back.
I'll give it a try too a let you know.
Hi Jake,
Your situation is really an Admin one-- it would seem you could create a new domain (not just a new Organization) with a new Domino Directory and make sure the default access to the new domain is not open to the other folks.
Have you looked at the server document security tab to fool with "Only allow server access to users listed in this Directory:" or "Access server:" or "Not access server:" ? I am still on R5, so these settings may be different for you in R6.
I did a project in R5 w/ address books and found that ($Users), ($People) and ($NamesFieldLookup) views were used for type-ahead. We had luck having a ($Users) view with a selection formula of "SELECT NULL." We kept the ($PeopleGroupsFlat) view so people could use the Address... button if they wanted, but deleted all other views except the People view. When we started in r4.6, we did not have the ($Users) view at all, but when we upgraded to R5, we were having problems, so adding that view back in with a Null selection formula seemed to clear it up. Note that the client will still open this address book and try to find a match (which takes a second). Found that the ($PeopleGroupsXXX) views are used for the Address... button.
This is obviously a hack, but might be helpful. Good luck.
-Seth
Richmond, VA USA
"I hate having to ask. Not only from a point of pride but also as I think it's an abuse of my position. "
You take yourself too seriously mate, for all of the info you have provided your entitled to ask a question.
How about placing a readers field on the person documents created for the web users. You could make the default value on the readers field of the person document a role. You could then just make sure that the general users don't have that role, so it shouldn't be available for type-ahead, right?
Put up a second server for your application, and give it a names=names,webnames line in notes.ini, creating a (deprecated) cascaded NAB. The first server (i.e. the one for the employees) doesn't get that. Your app registers new users into webnames.nsf. That does the trick for me.
Jake
In R4.6 days you could have a cascaded nab, in much the way Jan-Piet states in the above post. This worked briliantly in R4. But I think you need to use Directory Assistance in R5, can't remember if I ever got it working correctly. But it should be possible.
Works in R5 (5.0.12) and D6.
I haven't looked into your problem too much, but it seems extended ACLs would be an option.
I meant of course, that the cascaded NAB works fine and DA is not a requirement for it.
Jake,
This is a very good overview:
{Link}
And this is what I've done for similar situations (configure directory assistance):
{Link}
I hope this helps.
Victor
Yeah Jake... like Joe says... "You take yourself too seriously mate, for all of the info you have provided your entitled to ask a question."
You've saved me countless hours over the past several months... years.
Set up a directory assistance database, set up the location of the da database in your address book.
The database you are using as a secondary address book needs a Person form and a $Users and $People view for authentication. The Person form needs a few of the standard fields that exist on the NAB (FullName, HTTPPassword, etc... you should be able to figure these out).
See Administrator help for the details but this should solve your problem.
How about this: create a new domain for the application; let web users register into its PNAB; one way cross-certify the existing domain into the new domain; put a replica of the PNAB from the existing domain on the new-domain server, and configure its use through Directory Assistance.
This should give existing users rights in the new domain through existing certificates/passwords, but keep the new-domain PNAB invisible. It also isolates web users in their own domain.
Hi Jake,
I'm not a great expert in this field... but if it's an authentication issue you should be able to use a DSAPI filter to
validate against the 1st name and address book, and then if this fails, attempts validation on the 2nd name and address book.
I have done that many times.
You should configure the directory assistance database, create a secondary names,... exactly as Bob Obringer told you a couple of posts before.
IMHO directory assistance doesn't do the trick. Jake doesn't want to combine two different sources of addresses, his client wants to keep them separate, that is quite a different kettle of fish.
In the R4.6 days, I had to add NoMABForNames=1 to the server's notes.ini (where MAB means MasterAddressBook) to enable web users in the secondary, cascaded NAB to login via the web. Not sure whether this is still needed.
Good luck with your project!
Guys. Many, many thanks. As ever it's overwhelming that so many of you are willing/able to help.
Maybe I am taking it too seriously saying that I shouldn't ask questions. But when you say that I give out great info, that's why you come. You don't come because I ask for info. What I'll try and maintain is the right mix and never ask too many noddy questions....
Anyway, I've just got back from a two hour bike ride and can't take it all in yet. I need a sit down. I'll try and digest it tonight and report back on any success tomorrow.
Thanks again to you all.
Jake
Tsk, tsk; the guy is off cycling while we are racking our brains...
Well, you know what they say Jan-Piet. "Healthy body, healthy mind". Once I get the first you guys should pay with what the second can do ;o)
When you have a secondary address book in Directory Assistance, the user has to select it in the "Look in" combo box to display another directory.
What you can do is that every time your register someone in the secondary address book, you add him in a group in the primary address book (names.nsf) and use this group in the ACL of the secondary address book to prevent someone else to access it. Be sure that the group type is "Access control only" to prevent someone to use it to send e-mail to this group.
So, you can set up the ACL of your secondary address book to be accessible only by Admin and the new user registered via the web.
The employee inside the company will not have access to the secondary address book and then will not be able to send mail to these person.
And by the way, you have to set up the ACL of your names.nsf and the secondary address book to prevent anonymous access to these.
Yepp, Michaël led the way to go, I think. Unfortunately, enabling a secondary directory to authenticate web users is actually the same option that makes it available to Notes users. Many of the comments have been based on R5 and even R4 best practice. However, a lot has changed until then.
With R6 you can use one (non-LDAP) secondary directory to not only authenticate web users but also to provide group authorization (configured in DA). That was impossible in earilier releases. Furthermore web users can change their internet password directly by simply issuing a ?changePassword URL command (or clicking a corresonding link of course).
The directory itself ist now fully web browser enabled, so you can easily entitle an administrator on the customer's site to add and delete users or groups. Works very well with the exeption of a small bug, when adding people to groups, when their mail system is set to "none". First and last name are treated as seperate entries then and you have to fix this manually.
Another minor bug is, that the secondary directory *must* reside strictly within the root of the domino data folder. Otherwise the web client functionality won't work. Don't know if these issues (both due to bugs in the domino programming part of the names template) are fixed in the meantime, but I wouldn't bet my money on it.
Hi Jake,
I found this in the Sandbox. It's the Domino Registration Database. I assume you already looked at it, but perhaps this guy has a solution.
{Link}
Good luck!
The registration Database on Notes Net sounds like a good starting point. I know a developer who used it to register a set of web users and allow them access later on. Complications may come when you need SSO for the domain but can't have anonymous access to the database. The session login comes before the application checking for the registered web users. The Session login always goes to the address book(s) for the users. Check on how the domain is set up and how the web access is to be managed.
Lo all
Call that a stomach Jake? Pah! A small paunch perhaps. If you feel you should go out cycling because of that then perhaps I'd better start preparing for a round the world trek.
Anyway...to be honest it doesn't seem you have a problem. Surely the apps server will be single-tasked so you won't have mail users on it. If that's the case then there shouldn't be any reason why it can't be in a different domain. If it's in a different domain then there's no problem.
If it has to be in the same domain then, as long as it is a single-tasked server like I mentioned above, then there's still no problem. Put it in a different NNN - the other users won't see it. If it has to be in the same nnn, enable da on it but just that server, no others. Thus, da will work on the app server for authentication but none of the other servers will be set up for da so the other people won't see it.
There seem to be a fair few easy options for this - I wonder if I have misunderstood the question.
IMHO, easiest option is to put it in its own notes named network.
Seems all the solutions above are hell-bent on adding the external visitors to a/the company NAB.
Sack that right off. That's proper mad.
Why not just add them as a "Person Document" to a db of your own design, some kind of guestbook. Forget about all the domain palaver and the admin overheads that entails.
Then when a visitor returns, run them by the guest book entries first. If they are there, do whatever else do something else...
Or am I missing something? (Like the fact that I am stupid and have not read some crucial detail?)
James, that would involve writing your own authentication engine. Might as well let Domino do some of it.
Nah, just do a lookup into the guestbook db on their email address. As if someone had added a new product or whatever. Pull the details in, job's a good one.
Did something similar on for a company expenses claim db. Claimant requests a new form, gives their email address, it pre-fills in their details. No need to store all this with internal company mail.
" They want to register web visitors in a secondary address book so that they can then return at anytime and log back in to the application"
Or use a cookie on the client?
Guess what? This should be entirely possible in Domino 6, and without too much trouble to boot. Jason had the right answer waaaay up near the top--Extended ACL (xACL). I responded to your LDD question here:
{Link}
Looks to me that your first impression was correct. This did turn out to be an easy one...at least to implement. ;-)
As for ragging on Domino... Is it perfect? No. But it's definitely improving. From my perspective, they're doing a decent job of cutting away at the limitations. And Notes 6.5 looks great with the Sametime integration. And, as I've said before, I can't wait for the optional DB2 backend in Domino 7 sometime next year.
All of that said, it's always about using the right tool for the right job. Obviously that means something other than Domino in some situations. But with the depth of it's tool box, Domino is the right choice a lot of the time. At least to me.
Hope the xACL stuff helps ya.
- Rod