>> Ressourcen > Archiv > Maurer H. (Ed.)[..] > 11 Inside Hyper[..] > 11.2 Access per[..]

ErstesErstesVorherigesNächstesLetztes 2/6

11.2 Access permissions

 

Access rights are specified in the Rights attribute of a Hyper-G object (that includes documents, collections, and anchors). The attribute value is composed of read (R:), write (W:) and unlink (U:) permission fields, separated by semicolons. For each field, the value a means that the author of the object has access, u users means that the specified users (user names separated by blanks) have access, and g groups means that the members of the specified user groups (group names separated by blanks ) have access. While each field may appear only once, colons may be used to combine field values (e.g., R:a,u users,g groups).

The Rights attribute can only be modified by the author of the object or system users (i.e. members of user group system).

By default (that is, when no Rights attribute is present or a field is empty or missing) only the author of the object and members of the `system' group have write and unlink permissions while all users (including anonymous users) have read permission. In principle, the Rights attribute allows you to reduce the set of users having read access, to enlarge the set of users having write access, and to reduce the write access set to a set of users with unlink access.

Write access implies read access. Unlink permissions are only meaningful for collections, as they control the right to unlink (remove) something from that collection. By default (that is, if the unlink field is not present) users with write permission have unlink permission.

If the write field is present and the unlink field is not, the users specified by the write field also have unlink permission and can thus delete the object from the collection. Specifying the unlink field allows you to have collections where a (large) group of users may write documents into, but only a (small) group of users may remove documents from (can be used for hypertext discussion).

In addition to the Rights attribute, access is controlled by the TimeOpen and TimeExpire attributes. After the date specified by TimeExpire the object becomes invisible to users other not having write access to the object (the object is not physically removed from the database, however). Similarly, an object is invisible before the date specified by TimeOpen to users without write access to the object. See Section 22.3.1 for possible applications of the TimeOpen and TimeExpire attribute.

Summarizing, write access is granted, if:

  1. the user has system privileges (i.e. is a member of user group `system'), or
  2. the user is the author (owner) of the object, or
  3. the user is a member of the users or user groups specified in the write field (W:) of the object's Rights attribute.

Read access is granted, if:

  1. the user has write access (see above), or
  2. the time constraints are met (TimeOpen, TimeExpire), and

    1. The read field (R:) of the object's Rights attribute is not present or empty (i.e. unlimited read access granted), or
    2. the user is a member of the users or user groups specified in the read field of the object's Rights attribute.

Unlink access is granted, if:

  1. the user has system privileges (i.e. is a member of user group `system'), or
  2. the user is the author (owner) of the collection to unlink from, or
  3. the user has write access to the collection to unlink from (see above), and

    1. the unlink field (U:) of this collection is not present or empty, or
    2. the user is a member of the users or user groups specified in this field.

      As a special case, U:a refers to the author of the object to be deleted (not the author of the collection), so authors are allowed to delete their own objects only, even if they have write access to the collection.

Write (unlink) access for a document implies write (unlink) access for all anchors attached (i.e. even for private anchors of other users). The access permission contained in the Rights attributes are checked when the object (document, collection, anchor) is requested. In other words, if you do not have read permission for a document, you will not even be able to access its meta-data, let alone the document itself. But even if you have access permissions, you may not be allowed to fetch the document for other reasons (see Section 11.3).

Two more permission fields are allowed in the Rights attribute, although they do not directly control access to the object record. The I: field can be used to control the inheritance of a collection's access rights to its children. It is meaningful only for collections, and should be interpreted by a client wishing to insert something into the collection (it is not interpreted by the server), and suggested to the user as default Rights attribute. The I: is followed by a combination of the letters R, W, U, L and I. For example, I:R means that only the R: portion of the collection's Rights attribute should be copied to the client's Rights attribute. By default (that is, when the I: field is missing), clients should copy (inherit) all fields (equivalent to I:RWULI).

The L: field is meaningful for documents only, and used to limit simultaneous access to resources. It is described in detail in Section 11.3.

11.2.1 Examples 11.2.1 Examples