Modul: Register User v00.01.03, Userregistrierung im Frontend |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
Modul: Register User v00.01.03, Userregistrierung im Frontend |
Mon. 20. August 2007, 20:37
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 386 Mitglied seit: 12.07.2006 Mitglieds-Nr.: 136 |
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 ------------------------------------------------------------------------------------------------ # &-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)
-------------------- @bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo @bout LARP: LARP-Welt - CakePHP @bout Kites: Rodgauer Workshop - Contao |
|
|
Thu. 23. August 2007, 14:33
Beitrag
#2
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 541 Mitglied seit: 27.06.2006 Mitglieds-Nr.: 8 |
Hiho,
vorweg ZITAT 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. ZITAT ... 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. ZITAT 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!ZITAT 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ß |
|
|
Vereinfachte Darstellung | Aktuelles Datum: 21.9.24 - 09:18 |