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]

Hiho,

vorweg

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.

... ist schon klar. Ich respektiere deine Arbeit.

Ich finde es gut wenn Anregungen angenommen werden und der Dialog verbessert ja die Qualität des Modul/Code im hinblick auf eine breitere Nutzung.
Das mit den angekündigten Änderungen im Core schau ich mir an, hatte zwar im Hiterkopof eine zuletzt gegenteilige Meinung/Äußerung von Björn im Kopf
(... ja das war bei OpenId), doch das soll ja nicht schlecht sein. Ich hoffe nur das diese Erweiterungen maßvoll sind und nicht zuviel Funktionalität
in Core-Code übernommen wird, das schränkt nur die wiederwendbarkeit ein.

... oder ich werde über ein "Community-Plugin" nachdenken.

... guter Vorsatz, wurde shon mal angedacht. Ist für mich zur Zeit nicht Interessant,
mich interessieren eher Erweiterungen die auch im Business-Berech angewendet werden können. Dabei ist es grundsätzlich wünschenswert das es
Module/Plugins/Funktionalitäten gibt die (so wie die Registrierung) Dienste anbieten/realisieren. Zu diesen Diensten muss es vom Core natürlich definierte Schnittstellen geben (API)
die erweitert werden können. Dabei gilt die prämisse 'weniger ist mehr', es sollte kein verbauen sein sondern ein erweitern/anbieten.

Zur Blacklist, einfache Frage, (k)eine einfache Antwort; per CMS-Value. Einfach und gut pflegbar. Auch Erweiterungen/Änderungen über Modulupdates sind so möglich.

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

... gute Idee!

und ein mip-form mehr im Backendbereich. Kann ich machen!

... Das mit den User-Rechten, ja genauso meinte ich das.
Im Modul schreibst du den User ja schon in die dB wenn er sich anmeldet. Zur Aktivierung wartet das Modul auf den Validierungs-Link.
Das wäre der Zeitpunkt wo man die Gruppe nachträglich ändern könnte. Dazu halt eine Mipform mehr (optional) 'Gruppe während der Anmeldung'/'Gruppen nach der Anmeldung'.
Ein 'Keine Gruppe' geht ja gar nicht

Gruß