Names in IBM Domino – a warning!!

Ok, if you are like me you have worked with names in IBM Notes/Domino many, many times. And you may even have built your own directory solutions to put users into your application instead of in the central directory (like I have described in this article). If you have done the latter then you may have faced (or will in future) the dirty details of naming conventions in Domino…

I have this system where users can register themselves. I calculate a “full” name based on their name and a key that I create to ensure that the fullnames are unique. This is all well and works fine for login etc. etc. However, today I learned that you want to be careful with the naming. I only ever use the abbreviated name in this application. So I create an abbreviated name, say: “John Dalsgaard/12345/Org” and store this as the “FullName” in my user document (equivalent of the Person document in the Domino Directory). This all works well – apart from this situation:

If you have author access to the database and use an authors field to enforce the security model you have built into your logic – and you use a ROLE in the acl to give certain users access to delete documents created by other users – then you will find that these users will NOT be able to delete those documents although they have the role and the role is mentioned in the authors field!!

Ok, I use Java. So when I want to check for roles i use something like this:

getSession().getCurrentDatabase().queryAccessRoles("John Dalsgaard/12345/Org")

It returns the roles I would expect. So far so good. However, if I called:

NotesContext.getCurrent().isDocEditable(doc)

then that returns “false” – which reflects that the server is throwing errors at me! How can that be?

Next test is to try something simple:

getSession().evaluate("@UserRoles")

… no roles returned??? What on earth is going on? So I tried calling:

getSession().evaluate("@UserName").elementAt(0)

to ensure that I was who I thought I was!! It returned:

"John Dalsgaard/12345/Org"

and this is where some clever people who helped me (Paul Withers and Nathan Freemann) figured the problem was. It turns out that the FullName field of your user MUST be in the canonical format, i.e. the above SHOULD have been:

"CN=John Dalsgaard/OU=12345/O=Org"

When I changed my user document to have the full name in that format (and the same was reflected in the $Users view) then suddenly the roles were returned correctly from @UserRoles – and the delete worked! The odd thing that made it more difficult to track down was that the edit with a user that had his/her abbreviated name registered in the authors field actually WORKED. But please note that you should also ALWAYS use the canonical name in authors/readers fields – just to be safe!

You can read more about this on Paul Wither’s blog in this article – please pay special attention to the quote about formatting names.

 

 

4 Responses to Names in IBM Domino – a warning!!

  1. @Svar, I assume when you talk about self registering, we are talking “web”. We, like many others indeed, have gone through these motions long ago and we ended up with a different model through lots of thinking and testing,

    We do NOT use canonical names and enforce a valid email address as user name and we do not enforce registering real names. Email validity checking as wel as uniqueness checking is easy and uniqueness in the big world is a given. That might be something to disagree with, but we feel it is enough industry standard. Migration was…… interesting 😉

    What messes things up in this model is that the full name cannot have at sign, so in our secondary directory (which we use for web users) the full name is the email address with the at sign replaced with a tilde. This full name is then used internally for group population etc. Throw in some 32K limit handling on groups and you get the basic idea.

    We have never ran into any issues with this model. Any permissions through names, groups or roles has worked flawlessly.

    And yes, any canonical name is indeed always stored in the underlying documents in the full notation, with all labels. I can only advice to use a wrapper function for names fields handing to ensure that. But I realize that is water under the bridge now!

  2. @Jerone, yes I am talking “web”.

    I do the same sort of thing as you but just “calculate” the valid fullname differently – but still based on the email address to ensure uniqueness.

  3. @John (sorry about the name misread): Gotcha. Well, the “advantage” of the tracy~acme.com full name is you need no address lookup when doing mail, and, more importantly, no hierarchy issues! But to be honest, I did not realize it had such a nasty effect as you describe!.