'What is the best way to prevent access to the nsf through the notes client when developing xPages applications

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.

xpageslotus-noteslotus-domino


Solution 1:[1]

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

Solution 2:[2]

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).

Solution 3:[3]

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.

Solution 4:[4]

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.

Solution 5:[5]

  1. Create a new role in the database called "Admin"

  2. Put code in database script post open event that will use uidatabase.close if user do not have the admin role

  3. 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)

  4. 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.

Solution 6:[6]

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.

Solution 7:[7]

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.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Community
Solution 2
Solution 3 Aaron Brake
Solution 4 mark ambler
Solution 5 Thomas Adrian
Solution 6 David Navarre
Solution 7

Related Questions