WASD Web Environment

8.Web Document Update

The Update facility allows Web documents and file environments to be administered from a standard browser. This facility is available to Web administrator and user alike. Availability and capability depends on the authorization environment within the server.

It should be stressed that this is not designed as a full web administration or authoring tool, and for document preparation relies on the editing capabilities of the "<textarea>" widget of the user's browser. It does however, allow ad-hoc changes to be made to documents fairly easily, as well as allowing documents to be deleted, and directories to be created and deleted.

Consult the current Update documentation for usage detail.

And depending on site configuration /upd/wasd_root/ an example of the interface.

Update Access Permission

Of course, the user must have write (POST/PUT) access to the document or area on the server (i.e. the path) and the server account have file system permission to write into the parent directory.

Contact the Web Administrator for further information on the availablility of authentication and authorization permissions to do online updates of Web paths.

The server will report "Insufficient privilege or object protection violation ... /path/" if it does not have file system permission to write into a directory.

Write access by the server into VMS directories (using the POST or PUT HTTP methods) is controlled using VMS ACLs. This is in addition to the path authorization of the server itself of course! The requirement to have an ACL on the directory prevents inadvertant mapping/authorization of a path resulting in the ability to write somewhere not intended.

Two different ACLs implement two grades of access.

1. If the ACL grants CONTROL access to the server account then only VMS-authenticated usernames with security profiles can potentially write to the directory. Only potentially, because a further check is made to assess whether that VMS account in particular has write access.

   This example shows a suitable ACL that applies only to the original directory:

   $ SET SECURITY directory.DIR - /ACL=(IDENT=HTTP$SERVER,ACCESS=READ+CONTROL)
   This example shows setting an ACL that will propagate to created files and importantly, subdirectories:
   $ SET SECURITY directory.DIR - /ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+DELETE+CONTROL), - (IDENT=HTTP$SERVER,ACCESS=READ+WRITE+DELETE+CONTROL))
2. If the ACL grants WRITE access then the directory can be written into by any authenticated username for the authorized path.

   This example shows a suitable ACL that applies only to the original directory:

   $ SET SECURITY directory.DIR - /ACL=(IDENT=HTTP$SERVER,ACCESS=READ+WRITE)
   This example shows setting an ACL that will propagate to created files and importantly, subdirectories:
   $ SET SECURITY directory.DIR - /ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+DELETE), - (IDENT=HTTP$SERVER,ACCESS=READ+WRITE+DELETE))