Navigation

    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

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

    Archiv
    admin benutzer personen & gruppen rechte
    5
    13
    6780
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      LouR last edited by

      Ich nehme meine Frage standardbenutzer-admin-gegen-Änderung-schützen als Anlass für einen Feature Request.

      Request 1:
      Es soll nicht mehr möglich sein, dass ein Benutzer solange er z.B. einen Benutzernamen hinterlegt hat und oder mit Rechten in Churchtools ausgestattet ist, archiviert werden kann.

      Begründung: So kann verhindert werden, dass ein Benutzer von einem anderen Benutzer aus der Benutzung von CT ausgeschlossen werden kann, obwohl er nicht befugt ist Rechte zu geben oder zu nehmen

      Request 2:
      Es soll sichergestellt werden, dass jederzeit mindestens ein Benutzer mit dem ChurchCore Recht "Berechtigungen setzen, löschen und Benutzer simulieren (administer persons)" besteht.

      Begründung: So ist sichergestellt, dass mindestens ein Benutzer neue Rechte vergeben kann.

      Request 3
      Wie bereits im verlinkten Beitrag geschrieben, hätte ich gerne einen Kontakt als Benutzer, der nicht sichtbar ist und welchem alle Rechte von CT direkt zugewiesen sind.

      Begründung: Via diesem Benutzer wäre es jederzeit möglich einem Benutzer oder auch Gruppen, die benötigte Rechte zuzuordnen.

      Was denkt ihr über diesen Vorschlag?

      MaxStro 1 Reply Last reply Reply Quote 0
      • MaxStro
        MaxStro @LouR last edited by

        @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.

        1 Reply Last reply Reply Quote 0
        • L
          LouR last edited by

          @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.

          1 Reply Last reply Reply Quote 0
          • Andy
            Andy admin last edited by 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 1 Reply Last reply Reply Quote 0
            • MRBaum
              MRBaum @Andy last edited by

              @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 1 Reply Last reply Reply Quote 0
              • MaxStro
                MaxStro @MRBaum last edited by

                @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.

                1 Reply Last reply Reply Quote 0
                • L
                  LouR last edited by 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

                  1. Nur einem Benutzer das Recht zum Archivieren geben,
                  2. Sicherstellen, dass er keine Benutzerrechte in Gruppen ändern kann,
                  3. er keine Benutzerrechte geben oder wegnehmen kann,
                  4. 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 1 Reply Last reply Reply Quote 0
                  • MichaelG
                    MichaelG @LouR last edited by

                    @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).

                    L 1 Reply Last reply Reply Quote 1
                    • L
                      LouR @MichaelG last edited by

                      @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 1 Reply Last reply Reply Quote 0
                      • Andy
                        Andy admin @LouR last edited by Andy

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

                        L 1 Reply Last reply Reply Quote 0
                        • L
                          LouR @Andy last edited by

                          @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 1 Reply Last reply Reply Quote 0
                          • Andy
                            Andy admin @LouR last edited by 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.

                            L 1 Reply Last reply Reply Quote 0
                            • L
                              LouR @Andy last edited by 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

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post