CODEWITHSUNDEEP
xpageslotus-notesacllotus-domino
xpages-noob
xpages-noob

Reputation: 1579

Web user is not authorized to access a database despite having Editor access in the ACL

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?

Upvotes: 0

Views: 1500

Answers (4)

Emmanuel Gleizer
Emmanuel Gleizer

Reputation: 2018

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.

Upvotes: 2

John Dalsgaard
John Dalsgaard

Reputation: 2807

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

Upvotes: 1

&#201;ric Viala
&#201;ric Viala

Reputation: 616

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.

Upvotes: 1

stwissel
stwissel

Reputation: 20384

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.

Upvotes: 3

Related Questions