- Timestamp:
- 8 May 2015, 12:40:20 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/users.rst
r12917 r12918 4 4 ***** 5 5 6 Kofa distinguishes between four types of users: anonymous users, applicants, students, portal officers/managers and the Zope manager. Kofa distinguishes further between authenticated and unauthenticated users and between users with and without account object. 6 Kofa distinguishes between four types of users: anonymous users, 7 applicants, students, portal officers/managers and the Zope manager. 8 Kofa distinguishes further between authenticated and unauthenticated 9 users and between users with and without account object. 7 10 8 The user authentication process in Kofa is quite complex. Briefly and in simple terms, a so-called authenticator (plugin) validates the credentials provided via the login form, fetches the matching account object, extracts the account data and finally leads to the creation of a temporary user object, a so-called principal. Kofa principals provide `name`, `title`, `email`, `phone`, `public_name` and `user_type` attributes. 11 The user authentication process in Kofa is quite complex. Briefly 12 and in simple terms, a so-called authenticator (plugin) validates 13 the credentials provided via the login form, fetches the matching 14 account object, extracts the account data and finally leads to the 15 creation of a temporary user object, a so-called principal. Kofa 16 principals provide `name`, `title`, `email`, `phone`, `public_name` 17 and `user_type` attributes. 9 18 10 19 Anonymous 11 20 ========= 12 21 13 Anonymous users do not authenticate and thus do not provide credentials. Their user id in logfiles is always ``zope.anybody``. These users gain two permissions: :py:class:`Anonymous <waeup.kofa.permissions.Anonymous>` and :py:class:`Public <waeup.kofa.permissions.Public>`. 22 Anonymous users do not authenticate and thus do not provide 23 credentials. Their user id in logfiles is always ``zope.anybody``. 24 These users gain two permissions: :py:class:`Anonymous 25 <waeup.kofa.permissions.Anonymous>` and :py:class:`Public 26 <waeup.kofa.permissions.Public>`. 14 27 15 Only a few actions of anonymous users are logged. These are payment data webservice requests, the execution of password mandates and the self-registration of applicants. 28 Only a few actions of anonymous users are logged. These are payment 29 data webservice requests, the execution of password mandates and the 30 self-registration of applicants. 16 31 17 32 … … 19 34 ======================= 20 35 21 Logged-in applicants or students are regular authenticated Kofa users. Their user account object is an adaption of their applicant/student object. More precisely, the Applicant/Student authenticator fetches the matching applicant/student object and turns it on-the-fly into a Kofa account object which is further used for creating a principal instance. The `applicant_id`/`student_id` attribute becomes the user name and the `display_fullname` property serves as user title. 36 Logged-in applicants or students are regular authenticated Kofa 37 users. Their user account object is an adaption of their 38 applicant/student object. More precisely, the Applicant/Student 39 authenticator fetches the matching applicant/student object and 40 turns it on-the-fly into a Kofa account object which is further used 41 for creating a principal instance. The `applicant_id`/`student_id` 42 attribute becomes the user name and the `display_fullname` property 43 serves as user title. 22 44 23 45 … … 25 47 ======== 26 48 27 Officers are users with a dedicated user account object stored in the ``users`` container (of type :py:class:`UsersContainer <waeup.kofa.userscontainer.UsersContainer>`) which is located in Kofa's root container. The officer account object has two more attributes than the principal instance which is created from the account data: (1) a `roles` attribute which is a list of global role names assigned to the officer, and (2) a private `_local_roles` attribute. The latter maps local role names to lists of objects the respective local role applies to. This information is important because local role assignment is originally stored only with the objects the role applies to and not with the user who got the role. When removing a user, Kofa iterates over the mapping and the list of objects in order to remove all these local role assignments denoted in the mapping. 49 Officers are users with a dedicated user account object stored in 50 the ``users`` container (of type :py:class:`UsersContainer 51 <waeup.kofa.userscontainer.UsersContainer>`) which is located in 52 Kofa's root container. The officer account object has two more 53 attributes than the principal instance which is created from the 54 account data: (1) a `roles` attribute which is a list of global role 55 names assigned to the officer, and (2) a private `_local_roles` 56 attribute. The latter maps local role names to lists of objects the 57 respective local role applies to. This information is important 58 because local role assignment is originally stored only with the 59 objects the role applies to and not with the user who got the role. 60 When removing a user, Kofa iterates over the mapping and the list of 61 objects in order to remove all these local role assignments denoted 62 in the mapping. 28 63 29 The management of portal officers is done in the 'Officers' section of Kofa. The management page shoes all officers registered in the portal together with their global and local roles. The table can be easily sorted or filtered. 64 The management of portal officers is done in the 'Officers' section 65 of Kofa. The management page shoes all officers registered in the 66 portal together with their global and local roles. The table can be 67 easily sorted or filtered. 30 68 31 69 … … 33 71 ======= 34 72 35 There is one and only one manager account (user id ``zope.manager``) in Kofa. The manager has access to the root instance of the Kofa application which has its own user interface (see screenshot below). Through this 'Grok UI' the manager can access some basic functions to manage the database and also access the Kofa user interface. 73 There is one and only one manager account (user id ``zope.manager``) 74 in Kofa. The manager has access to the root instance of the Kofa 75 application which has its own user interface (see screenshot below). 76 Through this 'Grok UI' the manager can access some basic functions 77 to manage the database and also access the Kofa user interface. 36 78 37 79 .. image:: Grok_UI.png 38 80 39 Although the manager automatically gains all permissions the system defines, this real superuser (or emergency user) neither has an account in Kofa nor can access Kofa through its regular login page. The manager has to enter the portal through the Grok UI which usually ony runs on a localhost port, for example ``http://localhost:8080``. 81 Although the manager automatically gains all permissions the system 82 defines, this real superuser (or emergency user) neither has an 83 account in Kofa nor can access Kofa through its regular login page. 84 The manager has to enter the portal through the Grok UI which 85 usually ony runs on a localhost port, for example 86 ``http://localhost:8080``.
Note: See TracChangeset for help on using the changeset viewer.
