[ChurchDB] Deaktivierung Benutzern verhindern & Einführung eines geschützen Benutzers

MaxStro

@LouR zu 1: das ist problematisch, da Benutzer immer Rechte durch irgendwas (Status, Gruppe, etc.) erhalten. Vorher alle Rechte deaktivieren ist denke ich nicht drin und sinnvoll....

zu 2: würde sich doch mit Request 3 decken, oder? Ansonsten sinnvoll

zu 3: Unter Version 2.x war in der Konfig ein Admin hinterlegt (Allerdings ein normaler Benutzer). Einen Nichtsichtbaren Superuser finde ich problematisch, da man nicht weiß, wer alles die Zugangsdaten hat, wie und wer ändert diese? Man könnte ja nen eigenen Status und ne separate Person mit email anlegen, die alle Rechte hat, und alle anderen so konfigurieren, dass sie diese Person nicht sehen.

LouR

@MaxStro Ja verstehe ich, könnte man aber definieren, dass solange ein Kontakt einen Benutzernamen hinterlegt hat eine Archivierung nicht möglich ist? Auch nicht sonderlich sexy aber verhindert effektiv den Ausschluss eines Benutzers.

Request 2 und 3 - ja nach nochmaligem Durchlesen, sind die Anforderungen sehr ähnlich. Dein Argument von, "wer hat dann diese Superadmin Rechte" - das ist oft in Applikationen auch nicht per se klar. Das regle ich intern über den Applikationsverantwortlichen. Ich verstehe vermutlich was Du meinst mit Deinem Argument: Wenn der Superadmin dann beginnt in den Kontakten zu wühlen, ist nicht mehr klar wer die Änderungen in persona gemacht hatte.

Vielleicht könnte man aber folgende Einschränkung noch machen: ein Superadmin darf keine Personendaten anlegen und ändern. Somit müsste er zuerst einen Benutzer anlegen, sich dann anmelden und die Änderungen vornehmen. Diesen Aufwand wird sich kaum jemand antun, ausser der der absichtlich Böses tun will.

Andy

Ein (versehentlich) gelöschter CT-Admin könnte sich jederzeit den vollen Zugriff auf das System wiederholen, auch wenn er gelöscht/archiviert würde. Solange der Zugriff auf die Dateien (FTP) und die Datenbank (z. B. phpMyAdmin) möglich ist, sehe ich für diesen Fall keine Probleme.

Grundsätzlich sollte aber noch erwähnt werden, dass standardmäßig wohl (fast) alle Anwender mit einer 'echten' Person mit Admin-Zugang arbeiten. Ein eigener Account ist dafür m. E. eher unüblich. Also ich bin zumindest nie auf die Idee gekommen. Es soll im Log auch gesehen werden, welche Daten ich geändert oder angepasst habe.

MRBaum

@Andy Bei uns in der Firma arbeitet die IT so, dass jeder von den Admins einen zusätzlichen Admin Account hat. Also, wenn jemand was an dem Kernsystem ändern muss, dann muss er sich mit seinem zweiten User anmelden (z.B. admin.vorname.nachname).
Das erhöht dich Sicherheit, dass nicht "aus Versehen" jemand einen kritischen Prozess auslöst und trotzdem ist klar, wer wann was gemacht hat. Klingt vielleicht erstmal aufwändig, aber wir werden es wahrscheinlich am Ende auch so in ChurchTools machen.
Dann in der Regel nutze auch ich ChurchTools als "normaler" Gemeindemitarbeiter, und nicht als Admin.

MaxStro

@MRBaum Es gibt doch immer wieder Berechtigungen zu setzen und anzupassen. Dafür abmelden und extra als Admin wieder anmelden???

Die Frage sit, was überhaupt so grundlegende Einstellungen/Prozesse sind.

LouR

Also nochmals von vorne:

Was kann man tun, damit sich Benutzer nicht gegenseitig die Rechte wegnehmen können?
--> Der Vorgang ist, dass ein Benutzer ein Recht zum Archivieren hat und deshalb einen anderen aktiven Benutzer ins Archiv verschieben kann. Damit wird diesem Benutzer bekanntlich gleichzeitig die Möglichkeit genommen sich im CT anzumelden.

Option 1)

Bestehende Funktionalitäten nutzen

Nur einem Benutzer das Recht zum Archivieren geben,
Sicherstellen, dass er keine Benutzerrechte in Gruppen ändern kann,
er keine Benutzerrechte geben oder wegnehmen kann,
und zu guter Letzt, dass er den Benutzernamen nicht löschen oder ändern kann (Sicherheitslevel auf 3 oder sogar 4 setzen).

Vorteil: Keine Erweiterungen oder Änderungen in CT notwendig.
Nachteil: Vorallem das Archivierungsrecht wird so de facto zu einem "Superadministrator" Recht. Archivieren heisst aber auch, die Menge der aktiven Kontakte einzugrenzen (ein Abo mit 1000 Benutzer sind je nachdem schnell aufgebraucht).

Option 2)

Ein Benutzer, welcher in der Konfigurations Datei als Administrator aufgeführt ist kann nicht archiviert werden.

Vorteil: Es gibt mindestens ein Benutzer der über das Frontend von CT jederzeit Zugriff auf CT hat.
Nachteil: Ein solcher Benutzer muss zuerst über die Konfigurationsdatei "zurückgestuft" werden bevor er archiviert werden kann.

Option 3)

Ein Kontakt kann nicht archiviert werden, wenn ein Benutzername für diesen erfasst ist.

Vorteil: Über diesen Mechanismus und der Sicherheitsstufe z.B. 4 für das Feld Benutzername, kann verhindert werden, dass ein Benutzer bewusst oder versehentlich archiviert wird.
Nachteil: Es ist nicht offensichtlich, warum ein Kontakt nicht archiviert werden kann. Dies müsste vielleicht mit einem Hinweis beim Archivierungsversuch abgefangen werden.

Vielleicht könnt ihr Euch konkret zu den 3 Optionen nochmals äussern. Mir ist dieses Thema sehr wichtig - wie feststellbar ;-).

MichaelG

@LouR
Option 3 finde ich gar nicht gut.

Ich will, dass Leute sich einen Benutzernamen geben können (vereinfachter Login). Außerdem hat ja jede Person von Haus aus einen Benutzernamen (Name mit ID).

Ich versteh dein Anliegen, aber es an den Benutzernamen zu hängen finde ich nicht gut.

Wenn dann fände ich Option 2 brauchbar. Gesetzte Admins in der Config können nicht archiviert werden (mit Hinweis, falls man es versucht).

LouR

@MichaelG : Bist Du sicher, dass jeder Kontakt ein Benutzer ist? Bisher musste ich noch für jeden Benutzer explizt einen Benutzernamen erfassen.

Aber danke schon mal für Dein Feedback. Denke so können wir die beste Option sicherlich ermitteln.

Andy

@LouR Habe ich gestern getestet. Neue Person angelegt, ohne explizit einen Benutzernamen zu vergeben. Anmeldung über E-Mail-Adresse tadellos möglich.

LouR

@Andy Aha so hast Du gemeint. Ich hatte mich auf das explizite "Benutzername" Feld bezogen. Dieser Bezug zwischen Email und Benutzeranmeldung war mir so noch nicht klar. Damit würde ich die Option 3 dann auch eher ausscheiden.

Andy

@LouR sagte:

@Andy Aha so hast Du gemeint.

Was habe ich so gemeint?

Damit würde ich die Option 3 dann auch eher ausscheiden.

Auf jeden Fall. Der Meinung war ja auch @MichaelG schon.

Letztlich zählt bei der Anmeldung auch immer nur die E-Mail-Adresse. Haben z. B. 3 Personen die gleiche E-Mail-Adresse, aber unterschiedliche Benutzernamen, dann ist es egal, welchen Benutzernamen du bei der Anmeldung angibst ... die ChurchTools werden dich immer damit begrüßen, dass es zwei weitere Personen mit der gleichen E-Mail-Adresse gibt und du mögest bei Bedarf bitte über das Menü den Benutzer wechseln.

LouR

@Andy Ich wusste eben nicht, dass die Emailadresse den Benutzernamen übersteuert. Hatte das gar nie so probiert.
Und der zweite Teil vom Zitat, da wollte ich nur nochmals bestätigen, dass ich den Widerspruch zu Option 3 jetzt nachvollziehen kann.

Zu dieser sagen wir mal Eigenheit von Churchtools bezüglich Mehrfachverwendung von Emailadressen als Anmeldenamen gibt es ja auch schon einen Change Request dazu - http://forum.churchtools.de/topic/1996/unterschiedliche-personen-mit-gleicher-email-adresse-können-alle-anmeldungen-sehen/13