Register_XH

[cmb]

Hallo Holger,

zunächst mal vielen Dank für die Anregungen.

der Mailto-Link ist zunächst hart auf Deine Mailadresse gesetzt.

Das ist ein Bug. Meine eigene Adresse hat da natürlich nichts verloren.

Paginierung der User-Tabelle

Prinzipiell gut und richtig. Allerdings sollte es dann auch eine "richtige" Paginierung sein, so dass Datensätze, die nicht angezeigt werden, gar nicht erst zum Browser geschickt werden. Das würde dann auch die Performance-Probleme der Benutzerverwaltung lösen, die beim IE8 schon bei etwa 100 registrierten Benutzern spürbar werden. Allerdings erfordert das eine komplette Änderung der Datenspeicherungslogik; was ich eigentlich für 1.5 lieber nicht mehr machen will.

Such- bzw. Filterfunktion für User-Tabelle

Eine Suchfunktion gibt's doch schon: einfach STRG+F drücken (ggf. vorher die Details sichtbar machen). Für die Paginierung wäre dann aber eine Filtermöglichkeit notwendig.

Einer speziellen Gruppe (per Konfig definierbar) die Möglichkeit zur Administration der Usertabelle zu geben[1] (also ohne Admin-Mode des CMS)

Per Config finde ich das nicht so gut. Aber wie wäre es mit einer Funktion, die ähnlich wie Calendars editevents() im Frontend aufgerufen werden kann?

Welcome-Seite nach Usergroup

Das ist ja meine genannte Abwandlung von Emiles Vorschlag. Scheint also nützlich -- wird gemacht. Bei der Gelegenheit schau ich gleich mal, ob und wie eine ad-hoc Mail-Funktion für eine ganze Gruppe ergänzt werden kann.

Speichert er aber nicht, kommt beim Klick auf das Mailicon aber die check-dirty - Warnung des Browsers

Das ist mir beim Chrome auch aufgefallen. Beim IE 8, FF 16, Safari und Opera [1] löst der mailto: link dieses Verhalten aber nicht aus, das ich als Fehlverhalten des Browsers einstufen würde, da die Warnung im beforeunload Event ausgelöst wird, aber bei einem mailto: link das Dokument ja gar nicht "ungeloaded" wird. Ich schau aber mal, ob ich das mit vertretbarem Aufwand auch für den Chrome lösen kann. Alternativ sollte man sich vielleicht http://code.google.com/p/chromium/issue ... ?id=133625 anschließen (scheint bislang leider niemanden zu interessieren ).

Beim erneuten Überprüfen dieser Funktionalität ist mir noch ein Bug aufgefallen: die Sprachtexte werden nicht für JS escape't.

ob Du den Formularstatus (Details einblenden) nicht in einem Cookie sicherst (ja, ja, Cookie-Law...)

Das Speichern des Status ist wohl wirklich sinnvoll. Und um das Cookie-Law muss man sich hier wohl keine Sorgen machen: die Userverwaltung ist ja nur nach vorheriger Anmeldung zugänglich und dafür wurden ja bereits Cookies gesetzt.

Christoph

[1] Na ja, der Opera ignoriert das beforeunload Ereignis ja sowieso

[Holger]

Hi Christoph,

Prinzipiell gut und richtig. Allerdings sollte es dann auch eine "richtige" Paginierung sein, [...]was ich eigentlich für 1.5 lieber nicht mehr machen will.

Ja klar. Nur mal so als Anregung im Hinterkopf...

Per Config finde ich das nicht so gut. Aber wie wäre es mit einer Funktion, die ähnlich wie Calendars editevents() im Frontend aufgerufen werden kann?

Genau so meinte ich das. Nur, vielleicht etwas zu paranoid, zusätzlich noch ausschließlich an eine bestimmte Usergroup gebunden (muss aber auch nicht so sein - weil vielleicht dann doch verwirrend).

Das ist ja meine genannte Abwandlung von Emiles Vorschlag. Scheint also nützlich -- wird gemacht.

Genau. Prima!

Beim IE 8, FF 16, Safari und Opera [1] löst der mailto: link dieses Verhalten aber nicht aus

Hmm, FF 16.0.2 tut es aber doch (zumindest bei mir). Browserbug hin oder her, wenn es lösbar wäre, wäre das IMO deutlich besser.

Das Speichern des Status ist wohl wirklich sinnvoll.

Hmm, findest Du? Wenn ich nacheinander mehrere User bearbeite, muss jedes Mal das Details-Häckchen gesetzt werden. Das find' ich schon nervig. Aber man könnte dieses "Problem" ja leicht auch durch ein verstecktes Feld im Formular für zumindest den "Details-Status" lösen. Von der Sortierung rede ich ja garnicht - es gibt ja noch STRG-F .

LG
Holger

[cmb]

Hallo Holger,

Nur, vielleicht etwas zu paranoid, zusätzlich noch ausschließlich an eine bestimmte Usergroup gebunden (muss aber auch nicht so sein - weil vielleicht dann doch verwirrend).

Ich würd's schon lieber einfach halten, also nur die Funktion. Die kann ja auf einer geschützten Seite aufgerufen werden; gäb's noch eine Konfig-Option, dann könnte der Admin tatsächlich verwirrt werden, weil er den Seitenschutz und die Konfig-Option immer abstimmen muss. Und einen weiteren Vorteil hat es, wenn es einfach die Funktion (ohne Zugriffsschutz per se) gibt: dann kann diese Seite sogar mit Memberpages geschützt werden. Ein bisschen theoretisch, aber immerhin könnte so nur der Admin diejenigen Member bestimmen, die Zugriff auf die Benutzerverwaltung haben. Wird alles per Register_XH gemacht, dann kann ein "Benutzerverwalter" auch andere Benutzer in diese Gruppe aufnehmen (was vielleicht aber auch gerade so sein soll).

Dabei fällt mir ein: Register sollte eigentlich eine kleine API für andere Plugins zur Verfügung stellen, damit diese nicht auf die $_SESSION Variablen prüfen müssen (die ich wohl später mal ändern werde, um Nameclashes zu vermeiden). Diese API könnte einfach in den required_classes stehen, so dass sie unabhängig von der Ladereihenfolge immer verfügbar ist. Die API (mal auf die Schnelle):

Code: Select all

Register_currentUser()
    liefert den username des aktuellen Benutzers; false/null falls dieser nicht eingeloggt ist
// evtl. weitere Eigenschaften des Users abrufen können (email, Full Name)
Register_permitted($accessgroups)
    ob der aktuelle User etwas "darf" (d.h. Mitglied (einer) der angegebenen Gruppen ist) 

Hmm, FF 16.0.2 tut es aber doch (zumindest bei mir). Browserbug hin oder her, wenn es lösbar wäre, wäre das IMO deutlich besser.

Mein FF 16.0.2 meckert nicht

Das Speichern des Status ist wohl wirklich sinnvoll.

Hmm, findest Du? Wenn ich nacheinander mehrere User bearbeite, muss jedes Mal das Details-Häckchen gesetzt werden. Das find' ich schon nervig.

Ich auch; daher schrieb ich auch, dass das Speichern des Status wohl wirklich sinnvoll ist. Werde ich also machen; und die Sortierung und Filterung kann ich dann ja auch gleich speichern.

Christoph

[Traktorist]

Hallo Christoph,

@Ele: ich habe hier Register_loggedInForm() ergänzt (siehe Handbuch).

Danke

Auch wenn es mich sehr reizt, heute habe ich leider keine Zeit es mir anzusehen.
Ich mache es die Tage und berichte.

Viele Grüße, Ele

[cmb]

Hallo Zusammen,

ich habe gerade Register_XH 1.4pl1 und 1.5beta3 veröffentlicht. Das Update wird unbedingt empfohlen.

kmsmei hat berichtet, dass er sich bei einem Benutzerkonto mit einem ähnlichen Kennwort als dem erforderlichen anmelden konnte. Ich fand heraus, dass der Kennwort-Hash-Algorithmus von Register tatsächlich sehr schwach ist; daher habe ich beschlossen diesen zu ändern und den selben Algorithmus wie in CMSimple_XH > 1.5.4 zu verwenden.

Beachtet, dass dies alle alten Kennwörter ungültig macht!

Zu 1.5: ich habe mehrere der jüngsten Vorschläge noch nicht implementiert, da ich einen Sicherheits-Fix für wichtiger erachte. Die einzige wirkliche Verbesserung ist die individuelle Willkommensseite für jede Benutzergruppe. Wenn Ihr also 1.5beta2 oder früher nicht in einer Produktionsumgebung im Einsatz habt (wovon ich ausgehe ) und Ihr das neue Feature nicht braucht, dann könnt Ihr das Update einfach überspringen, und auf 1.5beta4 warten.

Christoph

[Joe]

Aber das

Since 1.4pl1 and 1.5beta3 the password hashing algorithm has changed, so your users old passwords won't work anymore.

ist nicht wahr, oder? Wenn CMSimple für eine Vereinsseite mit zig angemeldeten Usern betreibt, geht das GAR NICHT!!!!Ich kann UNMÖGLICH den ganzen Verein bitten, sich neu zu registrieren!!!

Ich hab 1.5beta2 installiert momentan. Wenn ich also 1.5beta3 installiere, kann sich keiner mehr einloggen? Hab ich das richtig verstanden? Kann man da nicht ein kleines Tool basteln, was die Passwörter umfriggelt, so das keine Neuregistrierung nötig ist?

Greetz
Joe

[cmb]

Hallo Joe,

ich hab Deinen Post mal ins dt. Forum verschoben.

Ich hab 1.5beta2 installiert momentan. Wenn ich also 1.5beta3 installiere, kann sich keiner mehr einloggen? Hab ich das richtig verstanden?

Ja, das ist leider richtig. Und ja: mir ist klar, dass das eine mittlere Katastrophe ist. Allerdings war das die alte Kennwort-"Verschlüsselung" auch wie ich seit gestern weiß. Daher ist die Umstellung mehr als sinnvoll, und sollte auch bald durchgeführt werden.

Einen Konvertierer für die Kennwörter hätte ich gleich mitgeliefert, wenn das möglich wäre. Aus einem Kennwort-Hash das ursprüngliche Kennwort herauszufinden ist nämlich nur per Trial and Error möglich (also alle möglichen Kennwörter probieren), und selbst dann ist nicht klar, ob man das wirkliche Kennwort, oder nur eines, das einen gleichen Hash ergibt, gefunden hat. Letzteres würde dann aber für diesen Zweck nicht helfen.

Aber ich habe eine Idee, wie man das Problem, dass alle Kennwörter ungültig werden, zumindest entschärfen kann. Dazu werde ich eine kleine Erweiterung schreiben, die man mit 1.4 bzw. 1.5beta2 mitlaufen lässt, und die bei jeder Anmeldung das eingegebene Kennwort mit der neuen Funktion "verschlüsselt" und zusammen mit dem Usernamen irgendwo ablegt. Dann können zumindest die Kennwörter derjenigen, die sich in der Zwischenzeit neu angemeldet hatten, übernommen werden. Den Übergangs-Zeitraum kannst Du (und andere) selbst bestimmen; allzu lange sollte es aber nicht sein (höchtens ein paar Wochen).

Christoph

[cmb]

Hallo Zusammen,

wie bereits im letzten Post angekündigt, habe ich den RegisterPasswordMigrator 1 entwickelt.

Christoph

[Joe]

uffff, klingt erstmal gut!!!

Aber:

müssen Sie die Datei
PasswordHash.php in das cmsimple/ Verzeichnis

wo finde ich PasswordHash.php ???

Gruss
Joe

[cmb]

Hallo Joe,

wo finde ich PasswordHash.php ???

Die sollte eigentlich im Download enthalten sein

Also bitte noch mal downloaden: RegisterPasswordMigrator 1.1

Christoph