Introduction

Public Access enables users to view (or create and edit) documents in cases where the user has not been explicitly granted access as either a reader or author of a particular document.

Up to now XPages applications were prevented from running if the user accessing the application only had the ability to read and write to Public Access documents. Now, in XPages Release 8.5.2, application designers can make XPages design elements available to Public Access users by setting the "Available to Public Access users" property in the Security sections of the Properties tab for an XPage.

Once an XPage has been made available to Public Access users, the user will only see

• documents
  1. that have been created from a form which the "Available to Public Access users" property set and
  2. also contain a text field named $PublicAccess with a value of 1
• contents of views
  1. that have the "Available to Public Access User" property set in the access control options for the view (and only those documents that are available to Public Access users will appear in the view).

 

 

 

Background

Public Access enables users to view (or create and edit) documents in cases where the user has not been explicitly granted access as either a reader or author of a particular document.

A general case would be Anonymous access to non-mail Lotus Domino applications on an external Web site that is accessed using a Web browser. Granting Anonymous access lets users connect to the server without authentication and allows access to users who have not been assigned an authorised user name/password in the Domino Directory.

Note: Public Access equally applies to authorised users who are are not on the Reader or Author list of a document, they will have access to any documents marked as available to Public Access users. This article will simply use the case of an Anonymous user by way of example of the Public Access functionality in XPages.

At the application Access Control List (ACL) level, the Anonymous user can have have a level of "No Access" set, which will by default give the user no access privileges alt all. The application designer then has the ability to optionally grant the "Read public documents" and/or "Write public documents" privileges to the user by selecting the appropriate access level privileges that are enabled for the chosen level of access.



By granting optional access level privileges to the user, the application designer allows user to view, create and edit, specific documents in the application that are controlled by forms that have been the "Available to Public Access users" attribute set in the Security tab of the Forms Properties box

Setting the "Available to Public Access Users" property on a form gives users with No Access or Depositor access the ability to view and modify specific documents created with the form without giving them Reader access or above in the ACL.



In addition, any documents that should be accessible to public access users must contain a field called $PublicAccess that is a text field with a default value of 1. A document is indicated to be public if it has a $PublicAccess field with a text value of “1.”


Then, once the user has the ACL option to "Read public documents" or "Write public documents" they can access the document accordingly.

Views also have a Public Access property. Typically, users who are not on the Readers list do not see the contents of a view.

If the view has the "Available to Public Access User" property set in the access control options for the view then those documents that are available to Public Access users will appear in the view.

Setting Public Access for XPages

Previously, a Public Access user (a user who only has the "No Access" or "Depositor" access levels with the Read/Write public documents access level privileges) was prevented from opening an XPage application. Now, XPages can be made available to Public Access users.

To make an XPage available to Public Access users, enable the "Available to Public Access users" property in the Security section of the Properties tab for the XPages Design Element.

Note: The XPages Public Access user setting is made in the Security section of the Properties tab (Window -> Show Eclipse Views -> Properties, if it is not already open) for the XPage Design Element Properties. This is not the same as the "XPage Properties" (XPage, Data, Style, Navigation, etc., which appear when an XPage is opened and selected in the Design/Source canvas. To see the "XPage Design Element Properties" (Info, Fields, Design, Security, etc.) select the XPage design element in the Application Navigator, then the Properties tab will change to show to related design element information.



If a user is a Public Access user and the the XPage is not available for Public Access users then a NoAccessSignal exception is thrown, which will cause the Web Browser to prompt the user to authenticate themselves.

Note: For XPages in the Notes Client, if a user does not have access to a particular XPage, a Security Exception is thrown instead of a NoAccessSignal, therefore the user is not prompted to log in in again. They will see a default error page, or other appropriate page that the application presents if it catches and handles the security exception.

Checking for Public Access in XPages

When running an XPage applications, initially, only the XPage is checked for Public Access. All the other design elements and controls are not checked to see if the XPage should be presented. However, the behaviour of the XPages UI Controls that compose the XPages can be affected.

Note: that a Public Access user that only has the "Write public documents" access level privilege, they will not get access to a Public Access XPages, the user must have at least the "Read public documents" privilege.

For example, the View Panel control that is based on a Domino View. If the View, that is defined as the the DataSource for the View Panel, does not make its data available to Public Access users, then the XPages View Panel UI controls will not display any data.


By making the data in the view available to Public Access users will return the document that can be read by Public Access users

while opening the same XPage as an authenticated user that has Reader access to all the documents will display more documents.

Troubleshooting

There are a number of scenarios related to Domino Document Data Sources. XPages that have a Domino Document as a data source are typically a data entry form. If the XPage is available to Public Access users, but the Form that the DataSource is based on is not available to Public Access Users then the user will be presented with the XPages data entry form, but when they go to save the data, they will set an error, because the From the Document is based on is not accessible and a NotesException is thrown.



The XPages run-time only checks the privileges granted to the User and not the components that comprise the XPage. Therefore, if a Public Access user without the "Write public documents" access level privilege tries to open an XPage (available to Public Access users) that has a Domino Document DataSource (based on a Form that is available to Public Access users, the XPages run-time will raise an NoAccessSignal exception that will cause the Web Browser to prompt the user to authenticate as a user who has the appropriate privileges. If they can not, permission to open the XPages will be denied.

 

 

 

Also, make sure you have set 'computeWithForm="both"' on the data source you are trying to save.



On a related note, if a Public Access user tries to open an XPage, either programmatically via an Open Page Server Side Simple Action, or via a URL, for example,

http:servexpages.nsf/xPerson.xsp?action=readDocument

the XPage rutime will check for a document ID. If no document ID is specified, then, even thought the requested mode was readDocument, XPages will attempt to create a new document. As the Public Access user does not have the privilege to create documents, a NoAccessSignal will be thrown and the Web Browser will prompt the user to login as a user with the appropriate access level privilege.

Finally, if a user tries to view a document they by using entering a URL directly into the Web Browser, e.g.

http://server/xpages.nsf/xPerson.xsp?documentId=ABCD44A3F2F008C68025776E00450E1A&action=readDocument

they will be prevented, and will see a stack trace with a NotesException: Invalid universal id.

com.ibm.xsp.FacesExceptionEx: Could not open the document
com.ibm.xsp.model.domino.DominoDocumentData.doOpenDocument(DominoDocumentData.java:422)
com.ibm.xsp.model.AbstractDocumentDataSource.openDocument(AbstractDocumentDataSource.java:148)
com.ibm.xsp.model.AbstractDocumentDataSource.load(AbstractDocumentDataSource.java:100)
com.ibm.xsp.model.AbstractDataSource.getDataContainer(AbstractDataSource.java:449)
com.ibm.xsp.model.domino.DominoDocumentData.getDataObject(DominoDocumentData.java:108)
....
....
NotesException: Invalid universal id
lotus.domino.local.Database.getDocumentByUNID(Database.java:346)
com.ibm.xsp.model.domino.DominoUtils.getDocumentById(DominoUtils.java:363)
com.ibm.xsp.model.domino.DominoUtils.getDocumentById(DominoUtils.java:384)
com.ibm.xsp.model.domino.DominoDocumentData.doOpenDocument(DominoDocumentData.java:411)
com.ibm.xsp.model.AbstractDocumentDataSource.openDocument(AbstractDocumentDataSource.java:148)