In der Sicht "Administration > Benutzerverwaltung" ist eine Regel eingebaut, dass man der "anonymous"-Benutzer nicht bearbeiten kann.

Öffnet man den "anonymous"-Benutzer im GOTO-Dialog, ist er dort jedoch sehr wohl bearbeitbar:

Des Weiteren sind die Buttons "Zugang entfernen" und "Benutzer löschen" auch für "anonymous" aktiv. Löscht man so den "anonymous"-Benutzer, kann man sich in die Anwendung nicht mehr einloggen: Es erscheint ein Error im Log [getNewSessionForUser] Given User is null. und im Browser ist nur noch diese Meldung zu lesen: Es ist nicht möglich, Cookies zu setzen. Bitte überprüfen Sie die Einstellungen Ihres Browsers.

Hier sollten die genannten Buttons für den "anonymous" Benutzer deaktiviert werden.

Ursache

Der Schutz des anonymen Zugangs (AnonymousAccountDisabled, #29447) hing als editExecutability an genau einem Formular der Benutzerverwaltung. Jede andere Sicht auf dasselbe Objekt – der Default-Dialog "Person", den ein GOTO öffnet, die übrigen Kommandos der Benutzerverwaltung, die Kontenverwaltung der React-Oberfläche – kannte die Regel nicht. Der PersonManager legt den anonymen Zugang nur beim Start an; wird er im laufenden Betrieb gelöscht, scheitert jede neue Session bis zum Neustart.

Die React-Kontenverwaltung (admin/access-control/accounts.view.xml) hatte zusätzlich keinen der Schutzmechanismen der klassischen Benutzerverwaltung: Löschen war auch für den eigenen Zugang und für Administratoren (z.B. root) möglich.

Lösung

• Globale Prüfung über den CommandApprovalService. AnonymousAccountDisabled ist in Konfigurationen des CommandApprovalService verwendbar. Das Framework konfiguriert die Regel für tl.accounts:Person (Kommandogruppen Write und Delete, tl.accounts.config.xml in com.top_logic.element) und für Contacts:PersonContact (Write, Zugang über account, contactConf.config.xml in com.top_logic.contact). Damit sind Bearbeiten, "Zugang entfernen", "MFA zurücksetzen" und "Persönliche Konfiguration zurücksetzen" für den anonymen Zugang in jeder Sicht deaktiviert, auch im GOTO-Dialog. Die formular-lokale editExecutability der Benutzerverwaltung entfällt.
• Die Funktion am account der Kontakt-Prüfung nennt ihre Implementierungsklasse (ScriptFunction1Impl) explizit, weil der per <defaults> konfigurierte Default innerhalb der Anwendungskonfiguration nicht greift – siehe #29742.
• Die Demo-Konfiguration des CommandApprovalService ersetzt die Framework-Konfiguration nicht mehr (config:override), sondern ergänzt sie.
• Löschschutz in der Datenbank. Person#tDeleteVeto() verweigert das Löschen des anonymen Zugangs. Der DeleteChecker weist die Löschung damit beim Commit zurück – unabhängig davon, über welche Oberfläche, welches Skript oder welchen Import sie ausgelöst wird. Der klassische Lösch-Befehl zeigt das Veto über DeleteVetoDisabledRule als Deaktivierungsgrund.
• React-Oberfläche.
  • ModelAccessPolicy fragt nach erlaubter Operation auf einem Objekt zusätzlich den CommandApprovalService (ohne Komponente und Kommando-ID). Jede <model-access>-Prüfung – explizit oder implizit durch eine Aktion – folgt damit derselben globalen Konfiguration; der Befehl wird deaktiviert oder ausgeblendet, wie die Prüfung es vorgibt.
  • Die Regel <delete-veto-disabled/> (DeleteVetoDisabled) deaktiviert einen Befehl, dessen Eingabe (oder ein Element davon) seine Löschung ablehnt (TLObject#tDeleteVeto()). <delete-object/> bringt sie implizit mit.
  • Der Bearbeiten-Befehl eines Formulars zeigt den Grund der Regel, die das Bearbeiten verweigert, als Tooltip.
  • Die Kontenverwaltung des Admin-Bereichs löscht über <delete-object/>, verweigert wie die klassische Benutzerverwaltung das Löschen des eigenen Zugangs und von Administratoren und prüft Write für die Passwort-/MFA-Befehle und den Bearbeitungsmodus des Formulars.

Migration

Die Prüfungen für den anonymen Zugang sind Teil der Framework-Konfiguration des CommandApprovalService. Eine Anwendung, die den Service mit config:override="true" selbst konfiguriert, verwirft diese Prüfungen. Das config:override an der Service-Konfiguration entfernen, damit die eigenen <check>-Einträge die des Frameworks ergänzen:

{{{#!xml <config service-class="com.top_logic.tool.execution.service.CommandApprovalService"> <instance class="com.top_logic.tool.execution.service.ConfiguredCommandApprovalService"> <check type="my.module:MyType"> ... </check> </instance> </config> }}}