[12829] | 1 | .. _users: |
---|
| 2 | |
---|
[12917] | 3 | Users |
---|
| 4 | ***** |
---|
[12915] | 5 | |
---|
[12918] | 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. |
---|
[12915] | 10 | |
---|
[12918] | 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. |
---|
[12915] | 18 | |
---|
[12922] | 19 | |
---|
[12915] | 20 | Anonymous |
---|
| 21 | ========= |
---|
| 22 | |
---|
[12918] | 23 | Anonymous users do not authenticate and thus do not provide |
---|
| 24 | credentials. Their user id in logfiles is always ``zope.anybody``. |
---|
| 25 | These users gain two permissions: :py:class:`Anonymous |
---|
| 26 | <waeup.kofa.permissions.Anonymous>` and :py:class:`Public |
---|
| 27 | <waeup.kofa.permissions.Public>`. |
---|
[12915] | 28 | |
---|
[12918] | 29 | Only a few actions of anonymous users are logged. These are payment |
---|
| 30 | data webservice requests, the execution of password mandates and the |
---|
| 31 | self-registration of applicants. |
---|
[12915] | 32 | |
---|
| 33 | |
---|
| 34 | Applicants and Students |
---|
| 35 | ======================= |
---|
| 36 | |
---|
[12918] | 37 | Logged-in applicants or students are regular authenticated Kofa |
---|
| 38 | users. Their user account object is an adaption of their |
---|
| 39 | applicant/student object. More precisely, the Applicant/Student |
---|
| 40 | authenticator fetches the matching applicant/student object and |
---|
| 41 | turns it on-the-fly into a Kofa account object which is further used |
---|
| 42 | for creating a principal instance. The `applicant_id`/`student_id` |
---|
| 43 | attribute becomes the user name and the `display_fullname` property |
---|
| 44 | serves as user title. |
---|
[12915] | 45 | |
---|
| 46 | |
---|
| 47 | Officers |
---|
| 48 | ======== |
---|
| 49 | |
---|
[12922] | 50 | .. seealso:: |
---|
| 51 | |
---|
| 52 | :ref:`Officers Doctests <userscontainer_txt>` |
---|
| 53 | |
---|
[12918] | 54 | Officers are users with a dedicated user account object stored in |
---|
| 55 | the ``users`` container (of type :py:class:`UsersContainer |
---|
| 56 | <waeup.kofa.userscontainer.UsersContainer>`) which is located in |
---|
| 57 | Kofa's root container. The officer account object has two more |
---|
| 58 | attributes than the principal instance which is created from the |
---|
| 59 | account data: (1) a `roles` attribute which is a list of global role |
---|
| 60 | names assigned to the officer, and (2) a private `_local_roles` |
---|
| 61 | attribute. The latter maps local role names to lists of objects the |
---|
| 62 | respective local role applies to. This information is important |
---|
| 63 | because local role assignment is originally stored only with the |
---|
| 64 | objects the role applies to and not with the user who got the role. |
---|
| 65 | When removing a user, Kofa iterates over the mapping and the list of |
---|
| 66 | objects in order to remove all these local role assignments denoted |
---|
| 67 | in the mapping. |
---|
[12915] | 68 | |
---|
[12918] | 69 | The management of portal officers is done in the 'Officers' section |
---|
| 70 | of Kofa. The management page shoes all officers registered in the |
---|
| 71 | portal together with their global and local roles. The table can be |
---|
| 72 | easily sorted or filtered. |
---|
[12915] | 73 | |
---|
| 74 | |
---|
| 75 | Manager |
---|
| 76 | ======= |
---|
| 77 | |
---|
[12918] | 78 | There is one and only one manager account (user id ``zope.manager``) |
---|
| 79 | in Kofa. The manager has access to the root instance of the Kofa |
---|
| 80 | application which has its own user interface (see screenshot below). |
---|
| 81 | Through this 'Grok UI' the manager can access some basic functions |
---|
| 82 | to manage the database and also access the Kofa user interface. |
---|
[12916] | 83 | |
---|
| 84 | .. image:: Grok_UI.png |
---|
| 85 | |
---|
[12918] | 86 | Although the manager automatically gains all permissions the system |
---|
| 87 | defines, this real superuser (or emergency user) neither has an |
---|
| 88 | account in Kofa nor can access Kofa through its regular login page. |
---|
| 89 | The manager has to enter the portal through the Grok UI which |
---|
| 90 | usually ony runs on a localhost port, for example |
---|
| 91 | ``http://localhost:8080``. |
---|