0

In my XPages application, web users can perform a self-registration. In the registration process, a user document for the web user is created in the address book and the user is added to a group that has Editor access for the database. After executing show nlcache reset on the Domino server, the user can login to and access the application.

In ~98% of all registrations this works perfectly fine. However, sometimes new users cannot enter the application after the login because, according to the Domino server, they "are not authorized to access" the database. The login must have worked because the user id is correct. The exact same user id can also be found in the Members field of the group that has Editor access to the database. To additionally verify the user's access level, I executed NotesDatabase.queryAccess() with the user's id. It returned 0, which is the ACL default and means "No Access". Yet, there are dozens of users in the same ACL group which have absolutely no problem with accessing the database.

At the moment, we "circumvent" this problem by manually removing the user's document from the address book as well as remove him/her from the Members of the ACL group. Afterwards we ask the user the re-do the self-registration with the exact same information as before. Up to now, this second registration has always worked and the user can access the application. Yet, this is not a real solution, which is why I have to ask if anyone knows what could be the problem?

xpages-noob
  • 1,569
  • 1
  • 10
  • 37
  • 1
    check if the self-registrated user has TWO consecutives spaces in his name, (could be because trailling space too) in group domino do a FullTrim. So we have JohnSmith that is not in group XXX because in the members it's JohnSmith. – Emmanuel Gleizer Feb 12 '15 at 11:16
  • @EmmanuelGleizer: The user names appear to be normal: No leading or trailing spaces, no double spaces. Also, the second registration, with the exact same credentials, has always worked up to now. Have you had a similar problem? – xpages-noob Feb 12 '15 at 11:41
  • are you using sessionAsSigner in your code? – Thomas Adrian Feb 12 '15 at 13:09
  • @ThomasAdrian: Yes, I use sessionAsSignerWithFullAccess to be able to create the user document in the address book. Do you think that this causes the problem? – xpages-noob Feb 12 '15 at 13:16
  • have a look here: http://stackoverflow.com/questions/27868299/erratic-failure-of-sessionassignerwithfullaccess – Thomas Adrian Feb 12 '15 at 13:17
  • @ThomasAdrian: Thanks for the hint, but I'm very sure that this is not the cause of my problem. The main registration process works fine: The user document is successfully created and the user is also added to the group. The problem is that after the Domino web login the user gets the information that he doesn't have access to the database with the id he is currently logged in with... – xpages-noob Feb 12 '15 at 13:25
  • 1
    Sounds familiar: http://www-10.lotus.com/ldd/nd8forum.nsf/5f27803bba85d8e285256bf10054620d/d0f8c79fa6605d408525749d001ae523?OpenDocument It links to Bruce Elgort's blog stating there is no need for "show nlcache reset" if you set notes.ini param "NLCACHE_VERSION=4" - which is default since 8.5.x (http://www-01.ibm.com/support/docview.wss?uid=swg21406274). So is there anything special about the users with access problem? – Frantisek Kossuth Feb 12 '15 at 15:42
  • Unfortunately, there does not seem to be anything special about these users. Even stranger is that the registration for the same user with the same credentials works if we let him/her do it a second time. PS: Thanks also for the hint with NLCACHE_VERSION. – xpages-noob Feb 12 '15 at 16:50
  • @EmmanuelGleizer: It turned out that you were right: Two consecutive spaces in the username caused the problem. We just didn't see the double space because we always outputted the names as HTML on a XPage (where multiple spaces look like one). Please add your comment as an answer because I'd be happy to give you credit for your advice. Thanks very much for your help! – xpages-noob Feb 25 '15 at 10:17
  • I experienced this too ;-) I know how you feel... should I have wrote my remark as a response – Emmanuel Gleizer Feb 25 '15 at 10:31

4 Answers4

3

Don't create entries in the address book directly. Use the adminp process for registration. To minimize perceived delay send a validation/confirmation message the user has to click.

stwissel
  • 20,110
  • 6
  • 54
  • 101
2

Comment of 12/02/2015 seems to be the correct Answer:

Check if the self-registrated user has TWO consecutives spaces in his name, (could be because trailling space too)

In group domino do a FullTrim. So we have 

John<space><space>Smith

that is not in group XXX because in the members it's:

John<space>Smith.
Emmanuel Gleizer
  • 1,990
  • 16
  • 26
1

This may have something to do with the frequency at which the views index are refreshed in the names.nsf

Since the access control is done groups in the ACL, the server will "know" which user belongs to which group only after the views index have been updated. In a normal setting, this can take a couple of minutes.

You can test this hypothesis by forcing an index refresh, either with CTRL-MAJ-F9 from your Notes client (warning, can take very long depending on network and number of entries in the names.nsf) or with the command

load updall -v names.nsf

... or by having the users wait a little while and try again 5min later.

Éric Viala
  • 596
  • 2
  • 12
  • Thanks for your answer. The next time we have an erroneous registration I will try your command. Btw: It is (probably) not a matter of the time passed since the user creation. The login problem persists for hours. Usually we fix the problem in less than 12 hours, so I can't say anything about longer timeframes. – xpages-noob Feb 12 '15 at 16:58
  • OK, so probably not an issue with view index refresh rate. Other hints I can think of follow. – Éric Viala Feb 15 '15 at 08:14
  • One key to orienting further research is the answer to the question "do you know exactly what's in there ?" More precisely, if it's a legacy system you've taken over recently, the previous guys may have left some funny stuffs in the corners. For example, check whether your names.nsf inherits from a standard template or a customized one. – Éric Viala Feb 15 '15 at 09:08
  • 1
    Now, the whole "self-registration process" sounds like a custom job, so your bug may very well be a custom one. Do you have skills and time to thoroughly review the design of this thing ? Does it keep any kind of logging ? Speaking of logging, have you checked the log.nsf and domlog.nsf ? You can tweak the log levels of both the http and server tasks. Note down exactly how the problem manifest itself. – Éric Viala Feb 15 '15 at 09:08
  • 1
    Any chance the new user end up belonging to more that one group, one of which with low ACL level ? Any charset issue ? Check effective access directly on the database's ACL box, will give you more detailled infos that the NotesDatabase.queryAccess() method. By the way, is it "the" database ? Any chance your app utilizes more that one DB ? Instead of making the user go again through the registration process, what happens if you (the admin) manually re-create the directory entry and insert said entry into relevant group ? – Éric Viala Feb 15 '15 at 09:08
  • 1
    Check the admin4.nsf , and generally be aware of the ways of the admin process. Check the relevant part of the app's acl. As somebody else mentionned, it's always better and safer to handle automated creation of users through a request to the admin process rather than directly writing in the names.nsf Any replication issue ? And finally, if I understand correctly, any person who requests it is automatically granted access to the app, so why not handling this through the "default" entry of the ACL ? What's the point of the group ? – Éric Viala Feb 15 '15 at 09:10
  • Wow, thanks for all the helpful hints. I wish I could upvote your answer more than just once :) About the registration process: Yes, it's a custom job, but the fact that it works correctly most of the time makes me assume that the problem has something to do with timing. About the logging: We already checked all the log databases and files - nothing critical and no warnings are logged during the registration. Also, I explicitely output what's happening during the registration to the console. This does not show any error, even for the "erroneous" registrations. – xpages-noob Feb 15 '15 at 11:33
  • About the "default" entry: Using this is not an option in our case because most users that register for the application are new, i.e. they do not have a web user account prior to the registration. As far as I know, "default" only applies to users that have created a valid session but cannot be found in the db's acl. – xpages-noob Feb 15 '15 at 11:38
  • Next time we face an erroneous registration we will again do ALL the checks you suggested. I will post the findings here. Thanks again for your help. – xpages-noob Feb 15 '15 at 11:40
1

Ok, first a question. If you let the user wait a couple of minutes will the access then work? I.e. is it a refresh/caching problem - or an inconsistency in the way you add the user to the group?

I assume that the format of the user name is correct as it works in most cases (i.e. fully hierarchical name)... Is there anything "special" about the names that do not work?

I do a similar thing (and has done several times) - although with some differences :-)

I typically use Directory Assistance to include my database with a "($Users)" view. When I update anything in this view I do a view.refresh() on the view (using Java). I typically do not use groups in these type of applications (either not applicable - or I use OU's or roles for specific users). I am not sure how the group membership is calculated - but I guess you could try to locate the relevant view (though none of them seemed obvious when I looked) - and do a refresh on it.

/John

John Dalsgaard
  • 2,797
  • 1
  • 14
  • 26
  • It does not seem to be a refresh/caching problem because even after waiting for hours the user's access level doesn't change. Also, the user names related to the erroneous registrations are not special. If I can't figure out how to solve this, I'll give your method with using the Directory Assistence a try. Thanks for this hint. – xpages-noob Feb 16 '15 at 07:35
  • Ok, that is actually great! Then there is something wrong in the way that you add the name to the group. Check that the names are correct in all places (i.e. hierarchical names).... – John Dalsgaard Feb 16 '15 at 09:24