I have an old local copy of a lotus notes database that I need to have the user's access to be read only. Right now they can open a record and change anything inside of it and save it.
Now for every view(role) to show up for anyone, I had to uncheck 'Enforce a consistent access control list across all replicas'
If I don't uncheck that, the views inside the database (records) are not visible. Is there any code I can insert in the database via Designer to lock this down?
thanks
You need to get the ACL (and any group memberships associated with it) right so that the users are assigned the correct roles. That way you can put the checkmark back on the "Enforce consistent access..." property without users losing access to the views.
I'm not 100% sure about this, but I think you'll need to have them pull new local replicas from your server after you correct the ACL in order for their Notes clients to recognize the change in their permissions.
Related
I have a navigation bar at the top of my Xpages applications. This element is going to be shared among many Xpage apps - it will work kind of like a intranet for our Xpage apps.
I do not want to display databases links to users who do not have access to the database.
How do I determine if a user can access a db? And is this something that I should somehow cache, so it doesn't have to be loaded again and again:
You can use the Database method queryAccess(name) to get the ACL level for the individual user. You can then check for No Access and for Depositor. Here's an example that returns true if the user has access to db:
db.queryAccess(userName) != ACL.LEVEL_NOACCESS && db.queryAccess(userName) != ACL.LEVEL_DEPOSITOR
I will suggest that you cache this in a user bean for the user.
Per's suggestion is great but be aware of one limitation on queryaccess:
From the documentation:
If the name you specify is listed explicitly in the ACL, queryAccess returns the access level for that ACL entry and does not check the groups.
If the name you specify is not listed explicitly in the ACL, queryAccess checks if the name is a member of a group in the primary Address Book known to the computer on which the script is running. On a local workstation, that address book is the Personal Address Book. On a server, that address book is the Domino® Directory. If queryAccess finds the name in one or more groups, it returns the highest access level among those groups. If the name you specify is not listed in the ACL either individually or as part of a group, queryAccess returns the default access level for the ACL.
First of all - if code runs under user's privileges, you can't call queryAccess for database you can't open. To work around this you could force the code to use signer's session and get the access. But...
I recommend this: make a bean named hasAccess. About the scope:
application scope is shared among users - useless
session scope - quite fine, but in case of ACL change
you would need to restart http or wait for session timeout
view scope is recommended
request scope wont help much
Implement map interface, so you can bind it like #{hasAccess[database]} where database will be filepath, or some special key to lookup database. Implement cache and return true/false, according to user's access. How do you determine user's access is up to you, but I think the best method is to use try/catch with attempt to open that database and check it with isOpen().
I don't want other users to see my database and documents inside it. There is something read/write privilege to users. I don't have clear picture about it.
If you want to hide the database names you have to use a proxy server in front of the CouchDB.
If it's ok to see the names of the DBs but the doc read access should be restricted - you can use the security settings of each DB.
A more granular write access control is enabled by using the validate_doc_update function of a design document (which you have to create inside a db by your own).
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?
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.
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.
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.
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
When developing xPages applications, what is the best practice for securing the nsf from a traditional Notes client. I would like to prevent any access to the database through the Notes client while having no impact to the xPage.
I would like to restrict access for a number of reasons. Security to the documents and the views, preventing users from using the application in notes and forcing them to use xPages. It looks like there is no silver bullet to accomplish this, but rather I need to use a number of different solutions.
You can't prevent it by ACL. You can redirect common users to open your application in browser, tho. In our applications, to prevent opening them in client and XPiNC, I have made simple subform with queryOpen script:
Dim ws as New NotesUIWorkspace
ws.URLOpen Source.Document.HttpUrl
Continue = False
This subform is put inside forms that user can get doclinks to or open from view. At view level you can adopt similar approach for all visible views and/or OpenDatabase script.
This works very well with this tweak: native Domino links and XPages
Why do you want to prevent access?
I assume that administrators and servers should be able to access the nsf. So LocalDomainAdmins, LocalDomainServers, etc. should be part of the ACL.
You can restrict user access from the Notes client to the nsf itself by making sure that user access groups in the ACL contain the names of user accounts (person documents in names.nsf) that have no matching Notes name (Notes id). The users can then only access the application from web and not from Notes.
But this might not be a feasible solution if users already have Notes access. Because then you have to create new person documents with user names that does not match the existing person documents, meaning that existing users then have a person document for Notes access and a person document for web access.
Instead you should perhaps look at restricting access to documents (using Readers fields) and views (through restricting access to a certain role).
I'd consider going even simpler on this and simply changing the launch property for the client to redirect to a page that indicates the user should access the application through a browser, and provide the URL to access the system. This isn't a perfect solution, depending on how information is disseminated in this system, but if users are simply opening the application through the notes client this would provide a good redirect as well as retraining the end user how the application is meant to be used in the future.
Split the app into two .nsfs. One for data other for only xpage design. Lock down the data .nsf and restrict it to only allow design signer access. It will cause some headaches as you will need to use sessionAsSigner to pull data.
Create a new role in the database called "Admin"
Put code in database script post open event that will use uidatabase.close if user do not have the admin role
Put script in alla views "query open" events with continue = false for all users without the admin role. ( this will prevent user from opening a view from the workspace using the go to view menu action)
Assign the "Admin" role in the acl only to the people that should be able to access it from the Notes client
You can also "hide" all views from Notes for everyone except the "Admin" role, but this might cause other problems depending on how the application is designed.
By either stripping the fields from the Forms or hiding all of them, you can make attempting to access the data in Notes unpalatable. You could then hide the views from the Notes client and make accessing the documents even more difficult (though someone could still create private views).
In one of our databases, the database opens to an XPage in XPiNC, which displays a link only for administrators to open the views.
var server:NotesName = session.createName(#Subset ( #DbName(), 1));
var filepath = database.getFilePath();
return "Notes://" + server.getCommon() + "/" + filepath + "/ViewToOpen?OpenView";
While it doesn't prevent the end user from accessing the Notes client version in all circumstances (someone could still send a doclink or view link), it allows users to follow their normal double-click pattern and open the database the way I want them to see it. With the link, I can allow such for those who really need Notes client access to it.
Maybe a bit late to the party, but here is our solution, to be put into the DatabaseScript PostOpen event.
#If(
#IsNotMember("[Admin]"; #UserRoles);
#Do(
httphostname := #DbLookup("" : "NoCache"; #ServerName : "names.nsf"; "($ServersLookup)"; #ServerName; "HTTP_HostName"; [FailSilent]);
#URLOpen("https://" + httphostname + "/" + #WebDbName);
#Command([FileCloseWindow])
);
""
)
This checks for the [Admin] role (to grant administrators backend access, could be left out if not needed) and if the user is not a member, gets the configured server hostname from the Domino server's addressbook, then builds and opens the URL in the browser, and finally closes the database.
Other than LotusScript in the PostOpen event, this #Formula code is capable of closing the database. And with this, you have all the code in one place only, and it gets triggered regardless if the user enters the db using a document or a view link or just opens the database via tile.
How can I let only managers to acces a certain view, what do i need to write in the PostOpen of the view(lotusscript),
TY very much guys
AFAIK there is a "Security Tab" in the view design editor where you can specify who (person,roles) can use the view. No script necessary. The view will be hidden for persons that is not allow to access the view.
As you are not describing in your question, why you want to hide the view, here are a view general comments:
Hiding a view from a group of people does not limit access to certain documents to this group of people. Unless the documents are otherwise protected, users can create private views and folders that display the documents shown in the restricted view. If you do not want to grant them access to the documents, please use reader fields.
"Managers" in the ACL have the right to change the database ACL, ... In regards to read access to documents, there is no difference to "Reader"s, as long as you are not using Reader fields in documents.
If you meant "Managers" as a role, please follow Peter's and Knuth's advice but keep in mind once more that limiting access to a view does not limit access to the documents via another view.
For more details on access rights, ... please take a look at Access levels in the ACL, Roles in the ACL, Creating read access lists to limit view and folder access and The Domino security model.