[0001]
[0002]
[0003]
[0004]
[0005]
[0006]
[0007]
[0008]
[0009]
[0010]
[0011]
[0012]
[0013]
[0014]
[0015]
[0016]
[0017]
[0018]
[0019]
[0020]
[0021]
[0022]
[0023]
[0024]
[0025]
[0026]
[0027]
[0028]
[0029]
[0030]
[0031]
[0032]
[0033]
[0034]
[0035]
[0036]
[0037]
[0038]
[0039]
[0040]
[0041]
[0042]
[0043]
[0044]
[0045]
[0046]
[0047]
[0048]
[0049]
[0050]
[0051]
[0052]
[0053]
[0054]
[0055]
[0056]
[0057]
[0058]
[0059]
[0060]
[0061]
[0062]
[0063]
[0064]
[0065]
[0066]
[0067]
[0068]
[0069]
[0070]
[0071]
[0072]
[0073]
[0074]
[0075]
[0076]
[0077]
[0078]
[0079]
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086]
[0087]

|1Web Document |*Upd||ate||

|^ The |*Upd||ate 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 |link%|/httpd/-/updhelp.html|current |*Upd||ate documentation|
for usage detail.

|^ And depending on site configuration |link%|/upd/wasd_root/| an example of
the interface.

|0Update 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.

|number|

|item| 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:

|code|
$ SET SECURITY directory.DIR -
  /ACL=(IDENT=HTTP$SERVER,ACCESS=READ+CONTROL)
|!code|

This example shows setting an ACL that will propagate to created files and
importantly, subdirectories:

|code|
$ SET SECURITY directory.DIR -
  /ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+DELETE+CONTROL), -
        (IDENT=HTTP$SERVER,ACCESS=READ+WRITE+DELETE+CONTROL))
|!code|

|item| 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:

|code|
$ SET SECURITY directory.DIR -
  /ACL=(IDENT=HTTP$SERVER,ACCESS=READ+WRITE)
|!code|

This example shows setting an ACL that will propagate to created files and
importantly, subdirectories:

|code|
$ SET SECURITY directory.DIR -
  /ACL=((IDENT=HTTP$SERVER,OPTIONS=DEFAULT,ACCESS=READ+WRITE+DELETE), -
        (IDENT=HTTP$SERVER,ACCESS=READ+WRITE+DELETE))
|!code|

|!number|