Changeset 12849


Ignore:
Timestamp:
12 Apr 2015, 13:15:00 (10 years ago)
Author:
uli
Message:

Wrap long lines.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/security.rst

    r12847 r12849  
    44********
    55
    6 Kofa has a very efficient security machinery. The machinery does not perform authorization checks on the content objects themselves stored in the database but restricts the usage of views, i.e. web pages and forms which are needed to view or edit data. Views are protected by permissions the user must have to use the view. Instead of assigning permissions seperately to users, permissions are bundled into sets of permissions, so-called roles which can be assigned to users through the web interface.
    7 
    8 It is important to note that permissions do not include other permissions. Only roles 'include' permissions. A 'manage' permission, for example, does not automatically enable users to open pages which merely display the data. These pages have their own 'view' permission. Another example is the ManagePortal permission described below. The name of the permission may lead to believe that users can do everything with this permssions. This is not true. It does only give access to certain pages which are dedicated to portal managers and must not be accessed by any other user.
     6Kofa has a very efficient security machinery. The machinery does not
     7perform authorization checks on the content objects themselves stored
     8in the database but restricts the usage of views, i.e. web pages and
     9forms which are needed to view or edit data. Views are protected by
     10permissions the user must have to use the view. Instead of assigning
     11permissions seperately to users, permissions are bundled into sets of
     12permissions, so-called roles which can be assigned to users through
     13the web interface.
     14
     15It is important to note that permissions do not include other
     16permissions. Only roles 'include' permissions. A 'manage' permission,
     17for example, does not automatically enable users to open pages which
     18merely display the data. These pages have their own 'view'
     19permission. Another example is the ManagePortal permission described
     20below. The name of the permission may lead to believe that users can
     21do everything with this permssions. This is not true. It does only
     22give access to certain pages which are dedicated to portal managers
     23and must not be accessed by any other user.
    924
    1025.. contents::
     
    1328===========
    1429
    15 The whole set of permission and role classes are described in the :py:mod:`Permissions and Roles Module<waeup.kofa.permissions>`. Here we describe only a subset of permission classes which are essential for the security settings configuration.
     30The whole set of permission and role classes are described in the
     31:py:mod:`Permissions and Roles Module<waeup.kofa.permissions>`. Here
     32we describe only a subset of permission classes which are essential
     33for the security settings configuration.
    1634
    1735General Permissions
     
    126144============
    127145
    128 Global or site roles are assigned portal-wide. In contrast to local roles, users have this role in every context.
    129 
    130 Many global roles do only bundle one or two permissions. The objective behind is to share responsibilities and distribute tasks.
     146Global or site roles are assigned portal-wide. In contrast to local
     147roles, users have this role in every context.
     148
     149Many global roles do only bundle one or two permissions. The objective
     150behind is to share responsibilities and distribute tasks.
    131151
    132152Global roles are being assigned via the user manage form page.
     
    162182   :noindex:
    163183
    164 In contrast to these specialized sets of permissions, there are two sets which delegate extensive powers on portal managers.
     184In contrast to these specialized sets of permissions, there are two
     185sets which delegate extensive powers on portal managers.
    165186
    166187.. autoclass:: waeup.kofa.permissions.PortalManager()
     
    173194--------------------------------
    174195
    175 Global Application Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the Application Section.
     196Global Application Section Roles are assigned portal-wide (globally)
     197but do actually only allocate permissions in the Application Section.
    176198
    177199.. autoclass:: waeup.kofa.applicants.permissions.ApplicantRole()
     
    187209----------------------------
    188210
    189 Global Student Section Roles are assigned portal-wide (globally) but do actually only allocate permissions in the Student Section.
     211Global Student Section Roles are assigned portal-wide (globally) but
     212do actually only allocate permissions in the Student Section.
    190213
    191214.. autoclass:: waeup.kofa.students.permissions.StudentRole()
     
    210233=======================================
    211234
    212 In contrast to global roles, which are assigned portal-wide, local role permissions are gained for a specific context.
    213 
    214 Some local roles serve a second purpose. At first glance it appears strange that some of these 'odd' roles do not give more permissions than the user already has due to other roles. Their real purpose is to delegate permissions to the students or application section. If a user has for example the LocalStudentsManager role described below at department level, s/he automatically gets the StudentsManager role for those students studying in this department. We call this a **dynamic role**. In contrast to static global or local roles, dynamic roles are not stored in the database, they are dynamically assigned.
    215 
    216 Local roles are assigned either automatically by the system during user object setup or manually through the web interface. The automatically assigned local roles are:
     235In contrast to global roles, which are assigned portal-wide, local
     236role permissions are gained for a specific context.
     237
     238Some local roles serve a second purpose. At first glance it appears
     239strange that some of these 'odd' roles do not give more permissions
     240than the user already has due to other roles. Their real purpose is to
     241delegate permissions to the students or application section. If a user
     242has for example the LocalStudentsManager role described below at
     243department level, s/he automatically gets the StudentsManager role for
     244those students studying in this department. We call this a **dynamic
     245role**. In contrast to static global or local roles, dynamic roles are
     246not stored in the database, they are dynamically assigned.
     247
     248Local roles are assigned either automatically by the system during
     249user object setup or manually through the web interface. The
     250automatically assigned local roles are:
    217251
    218252.. autoclass:: waeup.kofa.permissions.Owner()
     
    239273   :noindex:
    240274
    241 The following local roles do also delegate permissions to the student section. In other words, dynamic roles are assigned.
     275The following local roles do also delegate permissions to the student
     276section. In other words, dynamic roles are assigned.
    242277
    243278.. autoclass:: waeup.kofa.permissions.ClearanceOfficer()
Note: See TracChangeset for help on using the changeset viewer.