User Access Rights

User access rights are an important part of any Web server application. You need to be able to control who can view and modify the information your server provides. For example, let's say you are building a server application to handle online retail sales. It makes sense to allow users to view items in your catalog, but you don't want them to be able to change your prices! Clearly, access rights are an important issue.

Fortunately, WebSnap offers you several ways to control access to pages and server content. In previous topics, you saw how you can control page access by requiring logins. You have other options as well. For example:

You can show data fields in an edit box to users with appropriate modify access rights; other users will see the field contents, but not have the ability to edit them.
You can hide specific fields from users who don't have the correct view access rights.
You can prevent unauthorized users from receiving specific pages.

Descriptions for implementing these behaviors are included in this topic.

Dynamically displaying fields as edit or text boxes

If you use the adapter page producer, you can change the appearance of page elements for users with different access rights. For example, the Biolife demo (found in the WebSnap subdirectory of the Demos directory) contains a form page which shows all the information for a given species. The form appears when the user clicks a Details button on the grid. A user logged in as Will sees data displayed as plain text. Will is not allowed to modify the data, so the form doesn't give him a mechanism to do so. User Ellen does have modify permissions, so when Ellen views the form page, she sees a series of edit boxes which allow her to change field contents. Using access rights in this manner can save you from creating extra pages.

The appearance of some page elements, such as TAdapterDisplayField, is determined by its ViewMode property. If ViewMode is set to vmToggleOnAccess, the page element will appear as an edit box to users with modify access. Users without modify access will see plain text. Set the ViewMode property to vmToggleOnAccess to allow the page element's appearance and function to be determined dynamically.

A Web user list is a list of TWebUserListItem objects, one for each user who can login to the system. Permissions for users are stored in their Web user list item's AccessRights property. AccessRights is a text string, so you are free to specify permissions any way you like. Create a name for every kind of access right you want in your server application. If you want a user to have multiple access rights, separate items in the list with a space, semicolon or comma.

Access rights for fields are controlled by their ViewAccess and ModifyAccess properties. ViewAccess stores the name of the access rights needed to view a given field. ModifyAccess dictates what access rights are needed to modify field data. These properties appear in two places: in each field and in the adapter object that contains them.

Checking access rights is a two-step process. When deciding the appearance of a field in a page, the application first checks the field's own access rights. If the value is an empty string, the application then checks the access rights for the adapter which contains the field. If the adapter property is empty as well, the application will follow its default behavior. For modify access, the default behavior is to allow modifications by any user in the Web user list who has a non-empty AccessRights property. For view access, permission is automatically granted when no view access rights are specified.

Hiding fields and their contents

You can hide the contents of a field from users who don't have appropriate view permissions. First set the ViewAccess property for the field to match the permission you want users to have. Next, make sure that the ViewAccess for the field's page element is set to vmToggleOnAccess. The field caption will appear, but the value of the field won't.

Of course, it is often best to hide all references to the field when a user doesn't have view permissions. To do so, set the HideOptions for the field's page element to include hoHideOnNoDisplayAccess. Neither the caption nor the contents of the field will be displayed.

Preventing page access

You may decide that certain pages should not be accessible to unauthorized users. To grant check access rights before displaying pages, alter your call to the TWebPageInfo constructor in the Web request handler's AddWebModuleFactory command. This command appears in the initialization section of the source code for your module.

The constructor for TWebPageInfo takes up to 6 arguments. WebSnap usually leaves four of them set to default values (empty strings), so the call generally looks like this:

Copy Code

TWebPageInfo.Create([wpPublished, wpLoginRequired], '.html')

Copy Code

static TWebPageInit WebInit(__classid(TAdapterPageProducerPage3), crOnDemand, caCache, PageAccess << wpPublished /* << wpLoginRequired */, ".html", "", "", "", "");

To check permissions before granting access, you need to supply the string for the necessary permission in the sixth parameter. For example, let's say that the permission is called "Access". This is how you could modify the creator:

Copy Code

TWebPageInfo.Create([wpPublished, wpLoginRequired], '.html', '', '', '', 'Access')

Copy Code

static TWebPageInit WebInit(__classid(TAdapterPageProducerPage3), crOnDemand, caCache, PageAccess << wpPublished /* << wpLoginRequired */, ".html", "", "", "", "Access");

Access to the page will now be denied to anyone who lacks Access permission.

What do you think about this topic? Send feedback!