Register_XH

Ein CMSimple Support Forum für deutsch sprechende Nutzer und Entwickler
cmb
Posts: 13172
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Register_XH

Post by cmb » Sun Nov 25, 2012 12:24 pm

Hallo Holger,

zunächst mal vielen Dank für die Anregungen.
Holger wrote:der Mailto-Link ist zunächst hart auf Deine Mailadresse gesetzt.
Das ist ein Bug. Meine eigene Adresse hat da natürlich nichts verloren.
Holger wrote: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.
Holger wrote: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.
Holger wrote: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?
Holger wrote: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.
Holger wrote: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.
Holger wrote: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 ;)
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 2942
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany
Contact:

Re: Register_XH

Post by Holger » Sun Nov 25, 2012 2:26 pm

Hi Christoph,
cmb wrote: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...
cmb wrote: 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).
cmb wrote:Das ist ja meine genannte Abwandlung von Emiles Vorschlag. Scheint also nützlich -- wird gemacht.
Genau. Prima!
cmb wrote: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.
cmb wrote: 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 :mrgreen: .

LG
Holger

cmb
Posts: 13172
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Register_XH

Post by cmb » Sun Nov 25, 2012 3:08 pm

Hallo Holger,
Holger wrote: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) 
Holger wrote: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 :?
Holger wrote:
cmb wrote: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
Christoph M. Becker – Plugins for CMSimple_XH

Traktorist
Posts: 229
Joined: Mon Mar 07, 2011 4:34 pm
Location: South of Lower Saxony, Germany

Re: Register_XH

Post by Traktorist » Sun Nov 25, 2012 7:31 pm

Hallo Christoph,
cmb wrote:@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
Posts: 13172
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Register_XH

Post by cmb » Wed Dec 05, 2012 12:36 am

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
Christoph M. Becker – Plugins for CMSimple_XH

Joe
Posts: 89
Joined: Fri Mar 25, 2011 2:27 pm

Re: Register Plugin: weak password hashes

Post by Joe » Wed Dec 05, 2012 7:36 pm

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? :cry: :cry: :cry: 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
Posts: 13172
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Register_XH

Post by cmb » Wed Dec 05, 2012 8:29 pm

Hallo Joe,

ich hab Deinen Post mal ins dt. Forum verschoben.
Joe wrote: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
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 13172
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Register_XH

Post by cmb » Thu Dec 06, 2012 7:29 pm

Hallo Zusammen,

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

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

Joe
Posts: 89
Joined: Fri Mar 25, 2011 2:27 pm

Re: Register_XH

Post by Joe » Thu Dec 06, 2012 9:56 pm

uffff, klingt erstmal gut!!!

Aber:
müssen Sie die Datei
PasswordHash.php in das cmsimple/ Verzeichnis
wo finde ich PasswordHash.php ???

Gruss
Joe

cmb
Posts: 13172
Joined: Tue Jun 21, 2011 11:04 am
Location: Mü-Sa, RLP, DE
Contact:

Re: Register_XH

Post by cmb » Thu Dec 06, 2012 10:25 pm

Hallo Joe,
Joe wrote:wo finde ich PasswordHash.php ???
Die sollte eigentlich im Download enthalten sein :oops:

Also bitte noch mal downloaden: RegisterPasswordMigrator 1.1

Christoph
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply