Modul: Register User v00.01.03, Userregistrierung im Frontend Einstellungen

[Tiggr]

Titel: Register User

Status: alpha

Version: 00.01.03

Sefrengo- Version: 1.4

Beschreibung:
Ein Formular im Frontend ermöglicht es dem Besucher der Seite einen Benutzer anzulegen. Dabei werden nur die nötigsten Informationen abgefragt.

Demo:
http://colorfulsky.co.ohost.de/index.php?idcatside=2

Features:
- Alle Formulare, Meldungen und Ausgaben voll konfigurierbar.
- Benutzer erhält eine Mail mit einem Bestätigungslink, erst wenn dieser aufgerufen wird, ist der neue User aktiv.

Autor(en): Marcus Ertl (aka Tiggr)

Lizenz: GPL

Dokumentation: Keine

Installation:
Das Modul wird einfach wie gewohnt in Sefrengo eingespielt.

ABER:
Die Datenbank ist ein bißschen zu erweitern. Dazu liegt eine kleine Datei bei, solange das Tabellenprefix cms_ ist, sollte sie ihren Dienst verrichten. Einfach mit 'mysql <datenbank> < update_users.sql' anwenden. Oder halt mit User und Passwort, und so weiter, oder gern auch über phpMyAdmin.

Vor der Modulinstallation muß die Datei 'class.SF_ADMINISTRATION_User.php' in 'backend/API/ADMINISTRATION' durch die im Archiv hinterlegte ersetzt werden. Sicherheitskopie nicht vergessen!

Die Änderungen sind mit Björn abgesprochen, er wird das ganze aber noch prüfen, und vielleicht auch verwerfen... (vgl. password_recover_hash)

To Do:
- mod_rewrite im Maillink berücksichtigen
- Zeilenumbruch in der Mail
- Blacklist für verbotene Usernamen (STam)

QUELLTEXT

Changelog:
#  Bug Fix
+  Addition
^  Change
-  Removed
!  Note

23.08.2007 (tiggr) v00.01.03
------------------------------------------------------------------------------------------------
# E-Mails mit "modernen" TLD werden aktzeptiert (STam)
+ Zuweisung einer Gruppe und Aktivierung des Users schon vor Valierdierung möglich (STam)
- Keine DNS-Überprüfung der Emails mehr
! Funktionsnamen sauberer vergeben
! "Fremden Entfernt"

21.08.2007 (tiggr) v00.01.02
------------------------------------------------------------------------------------------------
+ Keine Abhängigkeit von register_globals=off mehr!

21.08.2007 (tiggr) v00.01.01
------------------------------------------------------------------------------------------------
# &amp;-Entität aus dem Maillink entfernt und durch & ersetzt

20.08.2007 (tiggr) v00.01.00
------------------------------------------------------------------------------------------------
! Initial Release

Testet das ganze bitte mal, ich hab es bisher nur im Testsystem ausprobiert...

Tschüss
Tiggr (aka Marcus)

Angehängte Datei(en)

 register_user_v00.01.03.zip ( 10.42KB ) Anzahl der Downloads: 91

 

[STam]

Schöne Idee und Umsetzung,
hier nur ein paar Gedanken:

• es wäre wichtig das es im Backend eine Übersicht von User mit dem Flag 'Validierung ausstehend' gibt
• es wäre wichtig eine Art 'garbage control' zu haben die ausstehende Validierungen mit Ablaufdatum aufräumt - steht zwar im Modul-Text, habe ich dann wohl übersehen?
• es wäre wichtig eine Blacklist von Namen zu haben die nicht erlaubt sind
• schön wäre es wenn die Email-Check Funktion auch .info oder sonstige tld mit mehr als 3 Zeichen erlaubt - einfach die Regexp tauschen reicht leider nicht aus,
  da RFC822-Mailadressen eine relativ komplexe Syntax haben können. Die meisten Prüfungen auf der Basis einer einfachen Regexp lehnen viele legale Adressen ab
  (Es existieren zum Beispiel inzwischen gültige Toplevel-Domains mit mehr als 3 Buchstaben: .info, .name) und lassen zugleich ungültige Adressen zu.
  Es wäre doch viel einfacher (und dazu noch der SFway) wenn die in SF enthaltenen PEAR::Mail_RFC822 genutzt wird.
  Die kann das ehe schon alles (und viel besser) und das Modul ist frei von irgend welchem Fremdcode.
• schön wäre es wenn Funktionen innerhalb von Modulen auch im Namesraum des Modul bleiben, das check_exists() ist zwar schön und gut, jedoch bei Funktionsnamen wie 'check_email_mx()' erledigt sich das mit der vielfalt und der entsprechenden Benennung irgendwann von selbst - private Modul-Methoden sollten den Präfix mod_... haben!
• schön wäre es wenn das Modul (als optionale Komponente) keine Core Änderung nachsich zieht, eine Erweiterung/Vererbung der API-Klasse ADMINISTRATION_USER zu ADMINISTRATION_USER_REG hätte gereicht und macht später anderen Registrierungsformen (wie OpenId) den weg einfacher. Schließlich lebt die API von Erweiterungen/Vererbung und nicht von Änderungen.
• schön wäre es auch wenn das Modul eigene Tabellen-Felder auch in einer eigenen Tabelle definiert (grundsätzliche Core-Änderungen mal ausgenommen)!
• schön wäre es wenn das Modul ein Captcha anbietet
• schön wäre es wenn es optional schon bei Anmeldung einen User-Staus (mit eingeschränkter-Gruppe) gibt und nach freischaltung einen Full-Status (erweiterte/volle Gruppen-Rechte)

... oje, das soll nicht den Eindruck erwecken das ich das Modul schlecht finde, ich habe mich nur damit beschäftigt

...gut gemacht weiter so

Gruß

[Tiggr]

Hallo!

Vielen Dank erstmal für die vielen Anregungen! :-) Find ich nicht schlimm, ganz im Gegenteil!

Erstmal so vorweg: Ich programmier vor allem für den Eigenbedarf, und hoffe immer, dass es auch andere gebrauchen können, deswegen strebe ich nicht immer die flexible Allgemeinlösung an! Sorry - aber ich möchte mich da einfach nicht verrennen! Auch wenn es vielleicht etwas egoistisch ist!

• es wäre wichtig das es im Backend eine Übersicht von User mit dem Flag 'Validierung ausstehend' gibt
• es wäre wichtig eine Art 'garbage control' zu haben die ausstehende Validierungen mit Ablaufdatum aufräumt - steht zwar im Modul-Text, habe ich dann wohl übersehen?

OK, das sind eigentlich 2 Dinge, aber ich seh beide als Aufgaben des Backends an. (Dazu später noch mehr, bitte das ganze Posting lesen! ;-)) Ich weiß noch nicht, was da kommt. Entweder wird die nächste Version von Sefrengo sowas enthalten, oder ich werde über ein "Community-Plugin" nachdenken. Das muß ich mal mit Björn klären, weil vieles in diesem Modul ist auf die Idee von Björn hin so entstanden.

• es wäre wichtig eine Blacklist von Namen zu haben die nicht erlaubt sind

OK, gute Idee! Würde ich einbauen wollen. Gibt es irgendwo schon wo eine Liste, die man als Basis verwenden kann? (Rassistische Namen und ähnliches...)

Wo würde diese Liste denn verwaltet? Ich glaube sowas sollte zentral gepflegt werden, nicht im Modul, oder?

• schön wäre es wenn die Email-Check Funktion auch .info oder sonstige tld mit mehr als 3 Zeichen erlaubt - einfach die Regexp tauschen reicht leider nicht aus, [...]
  Es wäre doch viel einfacher (und dazu noch der SFway) wenn die in SF enthaltenen PEAR::Mail_RFC822 genutzt wird. [...]

OK, einverstanden. Ich seh mir mal die PEAR-Klasse an! Kann aber einen Tick dauern! Dann fliegt auch wieder die Überprüfung der Domain per DNS raus, die macht mir etwas Bauchschmerzen...

• schön wäre es wenn Funktionen innerhalb von Modulen auch im Namesraum des Modul bleiben, das check_exists() ist zwar schön und gut, jedoch bei Funktionsnamen wie 'check_email_mx()' erledigt sich das mit der vielfalt und der entsprechenden Benennung irgendwann von selbst - private Modul-Methoden sollten den Präfix mod_... haben!

Guter Punkt, und nur eine kleine Änderung, wird umgesetzt!

Mal so als dumme Frage für die Zukunft: Sollen man nicht vielleicht versuchen Module als Klassen zu bauen, um sie besser zu kappseln?

• schön wäre es wenn das Modul (als optionale Komponente) keine Core Änderung nachsich zieht, eine Erweiterung/Vererbung der API-Klasse ADMINISTRATION_USER zu ADMINISTRATION_USER_REG hätte gereicht und macht später anderen Registrierungsformen (wie OpenId) den weg einfacher. Schließlich lebt die API von Erweiterungen/Vererbung und nicht von Änderungen.
• schön wäre es auch wenn das Modul eigene Tabellen-Felder auch in einer eigenen Tabelle definiert (grundsätzliche Core-Änderungen mal ausgenommen)!

Volle Zustimmung!

ABER: Die Änderungen an den Tabellen und an der API sind auf Anregung von Björn entstanden, der mir zugesichert hat, das die Änderungen in die nächste Sefrengo-Version mit einfließen!

Mehr dazu unter: password_recover_hash, was ist das?

Hier muss Björn noch mal sagen, was von der Community-Funktionalität Core-Funktionalität werden soll, und was wir als Plugin realisieren sollen. Du hast ja ganz zu recht oben angemerkt, das im jetzigen Usermanagment noch nichts davon unterstützt wird.

• schön wäre es wenn das Modul ein Captcha anbietet

Da hab ich mich bewußt dagegen entschieden, weil ich die Dinger für den Benutzer nur ätzend finde, ich glaubte, im Mailcheck genug Sicherheit zu haben. Natürlich kann ein Bot einen mit neuen Usern flooden, aber die werden dann ja (hoffentlich) nie aktiviert!

Ich würde auch nur sehr ungern Captchas einbauen... wie schon gesagt, ich find die Dinger sch....lecht!

• schön wäre es wenn es optional schon bei Anmeldung einen User-Staus (mit eingeschränkter-Gruppe) gibt und nach freischaltung einen Full-Status (erweiterte/volle Gruppen-Rechte)

Hmmm, find ich jetzt eher weniger sinnvoll , aber ich glaube das ist eine Zeile mehr im Frontend-Bereich des Moduls und ein mip-form mehr im Backendbereich. Kann ich machen!

Hab aber ein Problem: Ich brauch kurz Hilfe! Ich verwende im Backend

QUELLTEXT

$mip_form['10']['desc'] = 'Usergruppe';
$mip_form['10']['cat'] = 'app_group';
$mip_form['10']['output_cat'] = 'option';
$mip_form['10']['cms_var'] = 'MOD_VAR[10]';
$mip_form['10']['cms_val'] = $cms_mod['value']['10'];
$mip_form['10']['without_all_groups'] = true;
$mip_form['10']['with_admin'] = false;
$mip_form['10']['size'] = '1';

Um die Gruppenauswahl zu erzeugen! Ich habe es da noch nicht geschafft einen Eintrag "Keine Gruppe" rein zu bekommen! Das bräuchte ich dann nämlich sinnvoller Weise! Und ich will die mip-forms dafür nicht hacken!

... oje, das soll nicht den Eindruck erwecken das ich das Modul schlecht finde, ich habe mich nur damit beschäftigt
[/list]

Keine Angst, ich freu mich ja über jede Anregung, und vor allem darüber, das nicht umsonst gemacht zu haben. Ich hoffe es ist dann für dich auch ok, wenn ich mal bei dem einen oder anderen Punkt sage: Das will ich nicht! Wir sollten uns nur einigen, bevor wegen Kleinigkeiten 2 Module entstehen.

Tschüss
Tiggr (aka Marcus)