WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: evaki on October 11, 2017, 03:29:08 PM
-
WB-Benutzer mit zeitlich begrenztem Zugang.
Gab es schon Überlegungen die Benutzer-/Gruppenverwaltung dahingehend zu erweitern?
Hatte gerade wieder jemanden, der einen "Testzugang" für eine bestimmte Zeit benötigte.
Irgendwas aus der Trickkiste käme auch gelegen, da derartige Anfragen sich bei mir häufen.
Möglicherweise hab' ich auch mal wieder was übersehen... Laßt mich aber bitte nicht dumm sterben. :cry:
MfG. Evaki
-
wäre aus meiner Sicht eigentlich relativ easy umzusetzen. In der Benutzerverwaltung für den SuperAdmin oder Admin ein neues Feld mit Kalenderblatt, ein Feld in der Datenbank, Tabelle users, und beim Login diesen gesetzten Timestamp abfragen. ggf muß man das auch mit zwei Werten (von- bis) machen. Die Abfragen sind für die Section-Steuerung da, müssen nur angepasst werden, soll heißen, das schafft auch jemand ohne Informatiker-abschluß. So war mein Prinzip, das ich früher für Tester und Nutzer verwendet hatte, allerdings waren das reine PHP-Projekte und kein CMS wie z.b. WB. Dort sind es alles Sachen, die ohne einen Core-Hack nicht möglich sind
Komplizierter wird es, wenn man eine tägliche Zeitsteuerung haben möchte, z.B. Usergroup XY darf sich nur von 8-16 Uhr einloggen oder so und das dann noch kombinieren mit Zeitsteuerung von Datum zu Datum. Dann fängt man wohl mit den Rechten an
Allerdings habe ich in all den Jahren hier noch nie von einem Bedarf in dieser Richtung gehört. Keine Ahnung, wie die Zukunftspläne aussehen, aber gehört hab ich davon in meiner aktiven Zeit auch nichts, das in die Richtung gehen könnte (was aber nichts heißen muß)
-
Hatte das für ne WB 2.7 Seite eines Kunden über Cronejobskript realisiert:
- config.php (oder INI einbinden)
- Gruppe in WB-DB über SQL sperren (disable/löschen) wenn Testzeitraum abgelaufen
- Skript wurde einmal täglich ausgeführt und gut
- liese sich auch ohne Cronjob mittels include beim Login einbauen
Anfrage kam mir bisher aber nur einmal unter.
-
Dank für die Antworten.
Da bei "meinen" Anwendern Cronjobs ausführbar sind, wird das naheliegend vorerst die Lösung sein.
Möglicherweise wird auch "Jacobis" Lösung zur Anwendung kommen, falls der/die Anwender die nötigen Kenntnisse mitbringen (an den Core geh' ich nicht ran, und bei jedem Update iuharv0790a4g...). Beides erfordert bei uns dann Eingriffe, die nicht mehr allein vom WB-Admin getätigt werden können.
Für den WB-Admin wäre "Jacobis" Lösung natürlich die optimale -wenn's "eingebaut" wäre. Da dies zumindest bei Euch noch nie bzw. seltenst gebraucht wurde, wirds wohl ein Wunsch bleiben.
Falls noch andere WB'ler "sowas" brauchen, wäre es, zumindest für mich, gut zu wissen in welchem Rahmen es benötigt wird, wie z.B. Test- oder Gast-Zugänge.
MfG. Evaki
-
die Cronjob-Geschichte erwartet schon und auch jedes Mal Detailkenntnisse über den Aufbau der DB. Löscht man die Gruppe nach Ablauf der Zeitspanne, müßte man ja für den nächsten User wieder etwas anlegen in zwei Tabellen inkl. Rechtevergabe usw. Und hat man dieser zeitlich begrenzten Gruppe aus Versehen auch andere User zugeordnet, ist das Chaos perfekt. Außerdem muß man ja zum Anlegen solcher Gruppe immer den jeweiligen Code des Scripts anpassen, Userdaten eintragen usw.
So ganz erschließt sich mir der Sinn dafür noch nicht oder anders: bis ich das Script angepasst habe, habe ich per Backend drei Accounts eingerichtet und gelöscht.
-
Alles soweit richtig.
Doch haben die Anwender bzw. der WB-Admin Zugang zum Servermanagement (hängt wohl vom Hoster und dem Paket ab), welches individuell beschränkt konfiguriert werden kann, also wie WB selbst. Liegt ein vorgefertigtes Formular (Script) vor, das kriegt der "Server-Admin" noch hin, auch mal schnell die DB-Einträge (mit eindeutiger Bezeichnung z.B. der Gruppe) zu wechseln, womit es dann auch leicht für den WB-Admin zu nutzen ist.
Größere Bedenken kommen immer dann, wenns an den Core ran soll. Deshalb wahrscheinlich eher dieser Weg. Auch wenn Du ganz richtig liegst mit "bis ich das Script angepasst habe, habe ich per Backend drei Accounts eingerichtet und gelöscht." Dazu würde ich, wenns für mich persönlich wäre, auch neigen.
MfG. Evaki
Edit: @jacobi22: Hast mich aber soeben auf 'ne Idee gebracht. muß ich aber erstmal drüber nachdenken, obs nicht wieder was beklopptes ist. (Admin Tool)
-
AdminTool war auch mein erster Gedanke, wenn da der Login nicht wäre. Mit dem AdminTool (ggf UserExtent etc aufbohren bzw erweitern) kann ich mit und ohne aktuelle Corefunktionen die Maske zum Anlegen, Einstellen und Löschen solcher Usergroups bereit stellen, inkl. Anlegen der DB-Felder, aber spätestens beim Login muß ich dann an der Core ran.
Schade, das Entwickler für die einfachen User keine Zeit mehr haben, um mal eine grundsätzliche Auskunft zu geben, ob so etwas in Planung ist oder nicht. Vom Programmieraufwand würde ich sagen, viel länger als eine Stunde dauert es nicht.
-
Jepp, beim jetzigen späten Frühstück kam ich auch auf das Problem mit'm Login.
Aber auch die Frage nach der Methode der Deaktivierung stellte sich mir neu, zumindest wenn man zeitlich begrenzten und evtl wiederholten Zugang möchte, statt einfach nur zu löschen. Neue Tabelle fürs Tool und entsprechende Einträge tauschen (so mit Dummy un so) war der erste Gedanke. Aber da kommen bestimmt gescheitere Gedanken von Deiner und anderer Seite, zumals auch nur 'ne Assoziation war/ist.
Tja, und mit "viel länger als eine Stunde dauert es nicht." geht bei mir bekannterweise schon gar nicht, auch wenn mich das nicht davon abgehalten hat, mal ein oder zwei Module hinzubekommen. :-)
Bei meinen Fähigkeiten geh' ich möglicherweise beim 10ten in Rente :-D
MfG. Evaki
-
sag mal, was da für Hintergründe oder Notwendigkeiten bestehen.
Möchte man eine Online-Demo? (die gäbe es ja im Web)
-
Oooch die Entwickler lesen schon mit... und machen sich gelegentlich sogar auch Gedanken über die Probleme der "kleinen User". ;)
Die verschiedenen Ideen zu Einbindung solch einer Lösung hören sich im ersten Moment vielleicht einfach und verlockend an. Wenn man dann aber mal über alle möglichen Nebenwirkungen nachdenkt, kommt man recht schnell ins Grübeln.
Erst mal die größte Hürde: Allgemeine Regeln für Addons (https://wiki.WebsiteBaker.org/doku.php/dev/all/psr#allgemeine_regeln_fuer_addons) (die schon seit mehreren Jahren so geschrieben steht).
Somit scheidet eine Lösung, die den Core verändert oder direkt schreibend auf seine Daten zugreift, schon mal aus.
Selbstverständlich kann jeder mit seiner Installation machen, was immer er/sie/es will. Da spricht absolut nichts dagegen. Kritisch wird es erst, wenn diese Lösungen weitergegeben werden.
Speziell zur Zeit, da wir laufend sehr viel im Core ändern. Unter anderem auch an der Datenbank. Da ist nie sichergestellt, dass eine 'invasive' Lösung von heute auch morgen noch funktioniert und nicht gar das ganze System zum Absturz bringt (Zeitangaben bitte wörtlich nehmen).
Ok, das waren erst mal die 'Bedenken'. (N)
Jetzt aber auch ein wenig Erfreulicheres: (Y)
Selbstverständlich ist eine Lösung des Problems möglich. Sogar noch weitreichender als bisher angedacht. Man braucht nur vorhandenes mit etwas Neuem sinnvoll zu kombinieren, dann klappt das problemlos(naja, fast). ;-)
Frage: Was ist im aktuellen WB eigentlich notwendig, um für einen User das Login zu unterbinden?
Antwort: es muss nur ein einziges Bit in der Datenbank verändert werden. Das Feld users.active muss von 1 auf 0 oder umgekehrt gedreht werden und schon ist es mit dem Login vorbei.
Bedingung: falls das `active` bereits auf 0 war, darf es auf keinen Fall verändert werden! (das ist der Fall, falls ein User gesperrt ist oder noch nicht freigegeben etc..)
Eine Lösungsidee:
Die Zeitsteuerung läuft grundsätzlich Gruppenorientiert. Dies Gruppen werden in der normalen Gruppenverwaltung angelegt. Der Gruppe muss nur zusätzlich das Recht an dem Tool "NameDesZeitTools" gegeben werden.
Es sind beliebig viele 'Zeitgruppen' möglich
Die user können ganz normal über die Userverwaltung den Gruppen zugewiesen werden.
Alle Mitglieder einer Gruppe werden gleichzeitig aktiv oder passiv geschaltet, wenn die Zeitsteuerung das für die jeweilige Gruppe vorgibt.
Die Zeitsteuerung wird als eigenständiges Admin-Tool angelegt, welches auch einen direkten Aufruf zum Triggern der Zeitsteuerung zur Verfügung stellt. Die Ansteuerung kann z.B. so alle 12 Std. durch einen externen Cron-Job-Server (gibts im Netz auch kostenlos als Service) erfolgen. WB selbst hat derzeit etwas derartiges noch nicht eingebaut.
Die Verbindung zum Core (users+groups-Tabelle etc.) erfolgt über eine kleine Schnittstelle, die wir zur kurzfristig Verfügung stellen können und bei bedarf auch aktualisieren.
So kann sichergestellt werden, dass Änderungen am Core etc. an dem Zeit-Tool unbemerkt vorbeigehen. Auch sonstige Upgrades/Updates hätten keine Auswirkung. Das Tool braucht sich auch um kein Login und nichts zu scheren.
Kurzfassung der Schnittstellenmetho den:
array getGroupsList() // liefert alle Gruppen die das Recht zur Zeitsteuerung haben [group_id=>n, name=>xyz]
bool enableGroup(int $iGroupId) // aktiviert die angegebene Gruppe
bool disableGroup(int $iGroupId) // deaktiviert die angegebene Gruppe
mehr ist nicht notwendig. Wann welche Gruppe unter welchen Bedingungen ein-/ausgeschaltet wird, ist jetzt einzig nur noch Aufgabe des Tools. Das kann dann alles ohne irgendwelche Eingriffe in den Core erfolgen.
Falls sich also jemand an dem Teil versuchen will... sollte ich es bald wissen, sonst schafft es die Schnittstelle nicht mehr in das nächste Release, das gerade vorbereitet wird.
have a nice Day...
Manuela
-
Alle Mitglieder einer Gruppe werden gleichzeitig aktiv oder passiv geschaltet, wenn die Zeitsteuerung das für die jeweilige Gruppe vorgibt.
wäre das, was mir persönlich daran nicht gefallen würde, dann habe ich entweder ganz viele Gruppen mit z.b. unterschiedlichen Zeiten und vielleicht nur einem User pro Gruppe oder ich schließe mit einem Schalter alle User dieser Gruppe aus, unabhängig davon, ob der User XY schon aktiv war oder nicht
Ich würde da schon zu einem neuen Feld raten in der users-Tabelle mit einem timestamp zum ablauf. Ist der gesetzt, wird verglichen, ist er nicht gesetzt, gibt es Zugang. Der Aufwand wäre wesentlich geringer. Aber ich brauch es nicht, von daher...
-
Mit den Zeitgruppen wird es m.E. übersichlich, wenn man das ausschließlich für z.B. Gruppen wie Demo, Gäste oder Autoren (für zu erstellende Beiträge) anlegt. So zumindest war meine vorläufige Einschätzung, da ich auch die Vorstellung hatte, daß man das ja nicht jeden Tag macht.
Sind aber, bei Redaktionen eher häufiger, Autoren die Akteure, kann es wie m.E. "Jacobi" richtig feststellt, schnell unübersichtlich werden.
Ich dachte an Gruppen(namen) (z.B. Gastautoren, Sport am W.ende) wegen der Übersichtlichkeit, bei denen aber jeder Autor zeitlich geordneten Zugang erhält. Hab' auch erst jetzt -Tschuldigung- mal in die DB geschaut, und das Feld users.active gesehen. Was hält einen davon ab es unabhängig von einer Gruppe zu aktivieren/deaktivieren -unabhängig vom Programmieraufwand? Sind Änderungen in der Benutzerverwältung in Planung/Arbeit, die dann so ein Tool in kürzester Zeit wieder unbrauchbar machen, oder auch u.a. Auswirkungen auf Abfrage und Beschreiben der DB haben, eben auch unter Admin-Tools (deshalb auch Schnittstelle?)?
Fragen über Fragen, wenn man sich als Laie im fremden Terrain bewegt.
MfG. Evaki
-
Die Ergänzung auf User ist kein besonderes Problem.. nur 3 kleine Methoden mehr in der Schnittstelle.
App. Schnittstelle: Wir sind ja gerade dabei das ganze System zu 'entflechten'. Endlos viele Querverbindungen und Abhängigkeiten aufzulösen, damit das Ganze als solches wesentlich einfacher zu warten und ändern geht. Da wäre es mehr als kontraproduktiv, wenn wir jetzt wieder Zusätzliche Abhängigkeiten zwischen Module und Core einbauen würden. Deshalb eine Schnittstelle nach außen, die aus Sicht des Moduls immer gleich bleibt, ganz egal wie sich die 'Blackbox' namens Core verändert.
Andererseits kann das Modul auch alles was selbst benötigt in seiner/seinen eigenen Tabellen speichern, ohne auf Core-Tabellen etc. angewiesen zu sein.
Wie im PC auch... ich hab eine Busschnittstelle und da kann ich beliebige Zusatzkarten einstöpseln...
-
nur kurz zu eurer Aktiv-Schaltungs-Idee: users.active == 0 bedeutet (wie oben schon gesagt) - der User ist ist noch nicht freigeschalten (manuell oder Aktivierungsmail) oder eben nachträglich bewußt gesperrt, Gründe: egal. Es muß dem Bediener des möglichen AdminTools nicht unbedingt bekannt und auch nicht erkennbar sein, ob User XY nun bewußt gesperrt wurde oder ob grade seine zeitliche Berechtigung abgelaufen ist. Ihn dann ohne Nachkontrolle einfach so per Mausklick freizuschalten, kann eine Menge Ärger bringen. Wäre nichts, was ich reinen Gewissens empfehlen würde.
Auf meine Frage nach dem Sinn gab es keine richtige Antwort. Ich meine, zu verstehen, das es sich auch nicht um einmalige Freischaltungen handeln könnte, sondern eher so etwas wie der Eingabe im ProCalendar (z.b. immer Montags, Mittwoch und Freitags, 20.00 - 22.00 Uhr für die nächsten 8 Wochen). Damit wäre die Sache dann schon komplizierter und wäre nicht mehr so umsetzbar, wie ich mir das mit der eher einmaligen Freischaltung dachte. Man kommt aber so oder so nicht um den Core drum herum, egal, wie das Kind nachher heißt, Entflechtung, geheime Schnittstelle, Core-Hack- irgendwo muß ich ja in den Login-Prozeß eingreifen
-
>>Auf meine Frage nach dem Sinn gab es keine richtige Antwort.
Naja, hängt davon ab was man halt unter "richtig" erwartet. Die Vorgeschichte ist so, daß die Gründe für solche an mich herangetragene Ansinnen recht unterschiedlich waren, und die mir nun tröpfelweise wieder einfallen. Ich persönlich würde es nur für meine Demos brauchen. Und, - es handelte sich bei diesem Thema bisher immer um einmalige anlaßbedingte Freischaltungen.
>> irgendwo muß ich ja in den Login-Prozeß eingreifen
Wenn nicht aktiv (DB), dann kommste nicht (mehr) rein.
>>nur kurz zu eurer Aktiv-Schaltungs-Idee: users.active == 0
Ich habs so verstanden, daß nicht nur wg. Übersichtlichkeit die Sache gruppenorientiert gestaltet werden soll(te), da auch nur diese Gruppen für das Admin-Tool erreichbar sind bzw sein sollen. Wie und wo die Rechte hierfür vergeben werden ist für mich noch offen. Per dieser neuen Schnittstelle, oder gibts da noch andere Möglichkeiten?
MfG. Evaki
-
>> irgendwo muß ich ja in den Login-Prozeß eingreifen
Wenn nicht aktiv (DB), dann kommste nicht (mehr) rein.
users.active == 0 bedeutet (wie oben schon gesagt) - der User ist ist noch nicht freigeschalten (manuell oder Aktivierungsmail) oder eben nachträglich bewußt gesperrt, Gründe: egal. Es muß dem Bediener des möglichen AdminTools nicht unbedingt bekannt und auch nicht erkennbar sein, ob User XY nun bewußt gesperrt wurde oder ob grade seine zeitliche Berechtigung abgelaufen ist. Ihn dann ohne Nachkontrolle einfach so per Mausklick freizuschalten, kann eine Menge Ärger bringen. Wäre nichts, was ich reinen Gewissens empfehlen würde.
ich klink mich hier aus. Am Ende ist es Open Source, kann jeder machen, was er will
Für die active-Lösung braucht es aber auch kein Tool, das können die Berechtigten in der Benutzerverwaltung
-
Natürlich "kann jeder machen was er will" 8-)
Vielleicht hilft eine Erläuterung.
Wir bzw. die Anwender benutzen das CMS überwiegend als Redaktionssystem, also nicht als Blog, wo evtl. auch eine Sperrung infrage käme. Einzelne Mitglieder wie auch themenorientierte Zusammenschlüsse (Gruppen) sind aktiv, oder eben auch nicht. Es gibt also nur aktiv oder nicht aktiv.
Wer mehr Informationen über einen Benutzer-Status braucht, welche die aktuelle Benutzerverwaltung ja nicht hergibt, kann entsprechende Einstufung natürlich auch über solch ein Tool realisieren. Da waren Deine Gedanken "UserExtent etc aufbohren bzw erweitern", wenn ich das richtig eingeordnet habe, wohl schon ganz nah dran. Das geht aber über den ursprünglichen schlichten Wunsch weit hinaus, wird bei uns möglicherweise auch nicht gebraucht. Da habe ich bisher aber auch noch nicht weiter nachgehakt. Wenn die Benutzerverwaltung irgendwann aufgebohrt oder ersetzt wird, dürften solche Wünsche wohl "drin sein".
Mal schauen, ob ich überhaupt jemanden bei unseren Anwendern finde, der sich die Sache wenigstens mal näher anguckt. Mit dem Wünschen ist das ja so eine Sache... Manchmal sogar wie im Kindergarten:"Habi wolli". :-)
MfG. Evaki