Willkommen, Gast ( Anmelden | Registrierung )     [ Hilfe | Mitglieder | Suche ]

2 Seiten V   1 2 >  
Reply to this topicStart new topic
> Modul: Register User v00.01.03, Userregistrierung im Frontend
Tiggr
Beitrag 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
------------------------------------------------------------------------------------------------
# &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)
Angehängte Datei  register_user_v00.01.03.zip ( 10.42KB ) Anzahl der Downloads: 91
 


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
Guest_summerbrother_*
Beitrag Mon. 20. August 2007, 21:18
Beitrag #2





Guests






Goil...

-Installation kein Problem
-Anmeldung funktioniert
-Bestätigungsmail kommt
-beim Bestätigungslink wird nur die Registrierungsseite aufgerufen, ohne Meldung mit leerem Formular, User ist nicht aktiviert.

Umgebung: SF 1.4, Modul läuft im 3. von 7 Projekten in der Installation, keine anderen Sprachen.

Und die Edith gleich hinterher:

Der Aktivierunglink funktioniert wegen dem "&" nicht, da in der Mail die URL mit "&amp;" ankommt.
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Mon. 20. August 2007, 22:43
Beitrag #3


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

ZITAT(summerbrother @ Mon. 20. August 2007, 22:18) *
Der Aktivierunglink funktioniert wegen dem "&" nicht, da in der Mail die URL mit "&amp;" ankommt.


Komisch, bei mir tut es auch mit &amp;, ich dachte das gehört so! Ich benutze Thunderbird und Firefox...

Ich änder das morgen! Dann hoffentlich auch mit mod_rewrite-Unterstützung im Mail-Link!

Tschüss
Tiggr (aka Marcus)


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
bjoern
Beitrag Tue. 21. August 2007, 07:52
Beitrag #4


Administrator
********

Gruppe: Members
Beiträge: 1.092
Mitglied seit: 16.06.2006
Wohnort: Köln
Mitglieds-Nr.: 1



$sess->url() = mit &amp;
$sess->urlRaw() = ohne &amp;

Wie codiert das reinkommt (mit oder ohne &amp;) ist egal. Am Ende kommt es so raus, wie oben angegeben. &amp; ist bei XHTML Links wichtig, da es sonst einen Validierungsfehler gibt. In Mails funktioniert das nicht.


--------------------
Es wird, es wird...
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Tue. 21. August 2007, 13:51
Beitrag #5


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

Falls heute Abend mein Internet läuft, gibts ne Fehlerkorrigierte Version! Wir stellen nur gerade um auf 16000 DSL...

Tschüss
Tiggr (aka Marcus)


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Tue. 21. August 2007, 14:22
Beitrag #6


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

ZITAT
&amp; ist bei XHTML Links wichtig, da es sonst einen Validierungsfehler gibt. In Mails funktioniert das nicht.


Aha! Wieder was gelernt!

Tschüss
Tiggr (aka Marcus)


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Tue. 21. August 2007, 19:27
Beitrag #7


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

Ganz nach "release early, release often", hab ich das erste Posting upgedatet: Eine Version, in der der Maillink korrekt formatiert ist, also ohne Entität, sondern mit &!

Was noch immer offen ist, ist die Übernahme von schönen mod_rewrite-URLs auch in die Mail!

Und in der Mail bekomme ich noch unschöne Leerzeilen, wohl ein Problem mit dem CR-LF, wie löse ich das Problem denn richtig?

Tschüss
Tiggr (aka Marcus)
Angehängte Datei(en)
Angehängte Datei  2007_08_21_202342.png ( 51.03KB ) Anzahl der Downloads: 100
Angehängte Datei  2007_08_21_202450.png ( 51.65KB ) Anzahl der Downloads: 70
Angehängte Datei  2007_08_21_202556.png ( 42.86KB ) Anzahl der Downloads: 74
Angehängte Datei  2007_08_21_202623.png ( 47.16KB ) Anzahl der Downloads: 65
Angehängte Datei  2007_08_21_202644.png ( 51.82KB ) Anzahl der Downloads: 76
 


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
Guest_summerbrother_*
Beitrag Tue. 21. August 2007, 19:42
Beitrag #8





Guests






Na supi,
klappt alles, Update sauber, Maillink perfekt, Anmeldung funktioniert, Aktivierung ok.
Gute Arbeit.

Ich wollt jetzt noch ein paar Felder (Name Vorname, etc.) für die Anmeldung hinzufügen.
Macht das Sinn, das ich mich in den Code einarbeite ?
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Tue. 21. August 2007, 19:52
Beitrag #9


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

ZITAT
Ich wollt jetzt noch ein paar Felder (Name Vorname, etc.) für die Anmeldung hinzufügen.
Macht das Sinn, das ich mich in den Code einarbeite ?


Ich hab das erstmal bewußt einfach gehalten, damit ein anmeldewilliger User, der nur mal schnell einen Kommentar (mein nächstes Projekt) hinterlassen will, nicht gleich abgeschreckt wird.

Neue Felder aufzunehmen ist aber trotzdem einfach. Allerdings denke ich, da ist dann fast ein zweites Modul sinnvoll, in dem dann die Anmeldefelder gewählt werden können, und in dem Pflichtfelder gesetzt werden können.

Ich hab das so gesehen: Ich mach eine schnelle Anmeldung, und baue dann an den Stellen wo mehr gebraucht wird, entsprechende Abfragen ein.

Falls mal register_globals=off kommt, seh ich auch große Probleme mit meinem Code... :-(

OK, die Essenz dessen was ich sage ist: Sieh dir den Code mal an, ist verdammt einfach gehalten, und überleg dir, wie weit das sinnvoll erweiterbar ist. Ich denke, wenn du nur 2 Felder mehr brauchst ist das für ein individuelles Projekt schnell gemacht, ansonsten sollte man vielleicht was konfigurierbareres schreiben, mit einem flexibleren Ansatz!

Tschüss
Tiggr (aka Marcus)


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
gunwalt
Beitrag Tue. 21. August 2007, 21:03
Beitrag #10


Advanced Member
********

Gruppe: AdvancedMembers
Beiträge: 1.126
Mitglied seit: 27.06.2006
Mitglieds-Nr.: 7



ZITAT(Tiggr @ Tue. 21. August 2007, 20:52) *
Falls mal register_globals=off kommt, seh ich auch große Probleme mit meinem Code... :-(

Ich habe mir das Modul noch nicht angesehen, aber mit mit nicht abgesicherten Schwachstellen zu arbeiten, halte ich für ungut.
Zu dem Thema ct 18/2007, S. 178ff.


--------------------
------
Ich gehe spazieren durch Gelsenkirchen
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Tue. 21. August 2007, 21:31
Beitrag #11


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

ZITAT
Ich habe mir das Modul noch nicht angesehen, aber mit mit nicht abgesicherten Schwachstellen zu arbeiten, halte ich für ungut.
Zu dem Thema ct 18/2007, S. 178ff.


Jaja, c't-Leser! ;-)

Nein, ernsthaft: So groß ist die Sicherheitslücke nicht! Die Gefahr ist ja, das du Variablen per URL setzt, die irgendwo im Code verwendet werden. Beispiel: Wir nehmen ja gern eine Variable $sql um unsere SQL-Statments zu bauen. Nun könnte ja wer auf die Idee kommen, da eine url der Art '...?sql=select * from cms_users;' abzusetzen. Und schon passieren ungute Dinge! Aber nur, falls du die Variable nicht vorher sauber initialisierst! Also vor der ersten Verwendung immer erstmal $sql='';! Fertig ist der Braten! Nun kann nichts mehr geschehen! Saubere Programmierung. Wer "richtige Programmiersprachen" gewohnt ist, declariert oder initialisiert seine Variablen eh!

So, das meine persönliche Meinung dazu!

Momentaner Stand bei Sefrengo:

Schau mal in die index.php, da wird diese Lücke extra wieder geöffnet und die globalen Variablen wieder bereit gestellt, falls das per register_globals=off verboten wurde:

QUELLTEXT
// alle GET, POST und COOKIE wegen Globals_off parsen
$types_to_register = array('GET','POST','SERVER');
foreach ($types_to_register as $global_type) {
    $arr = @${'HTTP_'.$global_type.'_VARS'};
    if (@count($arr) > 0)
        extract($arr, EXTR_OVERWRITE);
    else {
        $arr = @${'_'.$global_type};
        if (@count($arr) > 0) extract($arr, EXTR_OVERWRITE);
    }
}


Hab ich einfach aus der index.php übernommen! Also im Moment ist das noch so üblich bei Sefrengo, da hab ich mich danach gerichtet.

Die Roadmap sieht mit der Version 1.6 vor, das das genau anders wird, register_globals muss dann off sein!

Wie das ganze dann aussieht, keine Ahnung, ich denke mal, es wird dann eine API geben, um auf den REQUEST zuzugreifen, vielleicht reicht es auch auf die Variabel $_REQUEST auszuweichen.

Gibt es ja eigentlich jetzt schon, oder? Zugriff auf $_GET, $_POST, $_COOKIE Variablen

OK, das mit dem Zugriff auf die Variablen ist mir erst jetzt eingefallen! :-( Bau ich mal bei Gelegenheit um! Aber wie schon gesagt: Zur Zeit bin ich nicht unsicherer als Sefrengo an sich! Und ich denke Sefrengo ist so sicher oder unsicher wie die meisten CMS.

Tschüss
Tiggr (aka Marcus)



--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Tue. 21. August 2007, 21:52
Beitrag #12


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



Hiho!

Noch schnell eine Version 00.01.02, keine Funktionalen Änderungen, oder irgendwas besonderes, ich hab mir nur die Kritik/Anregung von Guntram zu Herzen genommen: Das Modul sollte nun in Zukunft auch laufen, wenn register_globals=off gesetzt wird, und Sefrengo die register_globals=on auch nicht mehr simuliert! Wenn sich die API nicht ändert, ist es damit voll Sefrengo 1.6-tauglich! tongue.gif

Tschüss
Tiggr (aka Marcus)


--------------------
@bout Kites: Colorful Sky - Typo3
@bout LARP: Orga ohne Namen - Sefrengo
@bout LARP: LARP-Welt - CakePHP
@bout Kites: Rodgauer Workshop - Contao
Go to the top of the page
 
+Quote Post
STam
Beitrag Thu. 23. August 2007, 12:48
Beitrag #13


Advanced Member
********

Gruppe: AdvancedMembers
Beiträge: 541
Mitglied seit: 27.06.2006
Mitglieds-Nr.: 8



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 wink.gif

...gut gemacht weiter so

Gruß
Go to the top of the page
 
+Quote Post
Tiggr
Beitrag Thu. 23. August 2007, 13:42
Beitrag #14


Advanced Member
*******

Gruppe: AdvancedMembers
Beiträge: 386
Mitglied seit: 12.07.2006
Mitglieds-Nr.: 136



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!

ZITAT(STam @ Thu. 23. August 2007, 13:48) *
  • 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.

ZITAT
  • 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?

ZITAT
  • 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...

ZITAT
  • 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?

ZITAT
  • 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.

ZITAT
  • 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!

ZITAT
  • 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 wink.gif, 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!

ZITAT
    ... oje, das soll nicht den Eindruck erwecken das ich das Modul schlecht finde, ich habe mich nur damit beschäftigt wink.gif
    [/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)


    --------------------
    @bout Kites: Colorful Sky - Typo3
    @bout LARP: Orga ohne Namen - Sefrengo
    @bout LARP: LARP-Welt - CakePHP
    @bout Kites: Rodgauer Workshop - Contao
    Go to the top of the page
     
    +Quote Post
    STam
    Beitrag Thu. 23. August 2007, 14:33
    Beitrag #15


    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 wink.gif

    Gruß




    Go to the top of the page
     
    +Quote Post
    Tiggr
    Beitrag Thu. 23. August 2007, 15:53
    Beitrag #16


    Advanced Member
    *******

    Gruppe: AdvancedMembers
    Beiträge: 386
    Mitglied seit: 12.07.2006
    Mitglieds-Nr.: 136



    Hiho!

    ZITAT
    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.


    Ich hoffe auch sehr, dass die Entwicklung da hin geht: Ein schöner, stabiler, schlanker Core, und viele, viele Erweiterungen in Plugins, damit man sich sein Traumsystem bauen kann!

    Was sind für dich "Erweiterungen die auch im Business-Berech angewendet werden können"?

    Tschüss
    Tiggr (aka Marcus)


    --------------------
    @bout Kites: Colorful Sky - Typo3
    @bout LARP: Orga ohne Namen - Sefrengo
    @bout LARP: LARP-Welt - CakePHP
    @bout Kites: Rodgauer Workshop - Contao
    Go to the top of the page
     
    +Quote Post
    Tiggr
    Beitrag Thu. 23. August 2007, 15:55
    Beitrag #17


    Advanced Member
    *******

    Gruppe: AdvancedMembers
    Beiträge: 386
    Mitglied seit: 12.07.2006
    Mitglieds-Nr.: 136



    Und damit wir alles zusammen haben, ihr die Aussage von Björn zu den Datenbankfeldern:

    ZITAT
    Mach lieber ein neues Feld mit der Aufschrift 'registration_hash', wenn Du das Modul veröffentlichst, baue ich das Feld in der darauf folgenden Sefrengo Version fest ein.

    Wenn Du dabei bist, wäre es schön, wenn Du noch folgende Felder hinzufügen könntest
    acctep_agreement - 1 oder 0. Gibt an, ob der Benutzer die AGB bestätigt hat.
    acctep_agreement_timestamp - Zeitpunkt der angibt, wann der Benutzer die AGB bestätigt hat. Beide Felder klingen erst einmal blödsinnig, haben aber im Falle einer juristischen Auseinadersetzung Gewicht. Du kannst als Webseitenbetreiber nämlich nachweisen, dass User XY gegen die AGB verstoßen hat, die er zuvor bestätigt hat.
    registers_timestamp - Timestamp der Registrierung
    registration_valid - 0/ 1 Wert. Gibt an, ob ein Benutzer valide ist, also den Registrierenlink angeklickt hat. Bei der Registrierung im Backendformular steht der Wert natürlich gleich nach der Registrierung auf 1, wenn der Admin einen neuen user anlegt, sollte der ja schon wissen, was er tut. Außerdem lassen sich dann über den Flag besser karteileichen aussortieren.
    registriation_validated_timestamp - Timestamp, wann der Benutzer die Registrierung akzeptiert hat.


    Tschüss
    Tiggr (aka Marcus)


    --------------------
    @bout Kites: Colorful Sky - Typo3
    @bout LARP: Orga ohne Namen - Sefrengo
    @bout LARP: LARP-Welt - CakePHP
    @bout Kites: Rodgauer Workshop - Contao
    Go to the top of the page
     
    +Quote Post
    Tiggr
    Beitrag Thu. 23. August 2007, 18:13
    Beitrag #18


    Advanced Member
    *******

    Gruppe: AdvancedMembers
    Beiträge: 386
    Mitglied seit: 12.07.2006
    Mitglieds-Nr.: 136



    Hiho!

    Erster Kommentar: Ich hab mir die PEAR::Mail_RFC822 angesehen, mit dem Fazit: Die taugt für meinen Zweck nicht!

    Die prüft wirklich ganz streng, ob eine Mail der RFC822 genügt, aber die Anforderungen sind nicht hoch genug, die an die Adresse sind nicht hoch genug, wir können ja nur eine Untermenge von gültigen Adressen gebrauchen.

    So läßt PEAR::Mail_RFC822 die folgende Mail-Addi als gültig durch: fsdfasfs@fsdfsdfsf! Recht hat sie, nach reiner Logik haben wir eine Mailbox und einen Host angegeben, ist eine Adresse wie auch root@localhost, vollkommen zulässig also! Aber im Webbereich eher unglaubwürdig.

    OK, also doch eine einfache Überprüfung per regex!

    Tschüss
    Tiggr (aka Marcus)


    --------------------
    @bout Kites: Colorful Sky - Typo3
    @bout LARP: Orga ohne Namen - Sefrengo
    @bout LARP: LARP-Welt - CakePHP
    @bout Kites: Rodgauer Workshop - Contao
    Go to the top of the page
     
    +Quote Post
    Tiggr
    Beitrag Thu. 23. August 2007, 18:59
    Beitrag #19


    Advanced Member
    *******

    Gruppe: AdvancedMembers
    Beiträge: 386
    Mitglied seit: 12.07.2006
    Mitglieds-Nr.: 136



    Hiho!

    Und eine neue Version!

    - Ich hab die Funktion(en) sauber benannt, beginnen jetzt mit "mod_registerUser_"! Guter Hinweis, Danke!

    - Es werden nun lange Toplevel-Domains aktzeptiert! Ich hab die Regex aus dem Kontaktformular geklaut, und TLDs bis 6 Zeichen erlaubt. PEAR::Mail_RFC822 hat sich leider als für die Anwendung wenig geeignet erwiesen!

    - Ich hab die Überprüfung der Mail per DNS deaktiviert, war mir nicht sicher, ob das immer gut läuft, lieber mal eine falsche durchlassen, als gültige E-Mails aussperren.

    - Jetzt ist es möglich, den neuen User schon vor der Validierung zu aktivieren, und ihm vor und nach der Validierung unterschiedlichen Gruppen zuzuweisen! :-)

    - Offen bleibt die Blacklist für Namen! Nicht weil ich sie nicht will, ganz im Gegenteil, ich überlege nur, wie man das sinnvoll verwaltet. Außerdem weiß ich nicht, wie ich mit Variationen des Namens umgehen soll (unbedenkliches Beispiel): Mozart, Mozahrt, Mozzart, M0zart, m0z4rt, mohzarrt, ... da komm ich selbst mit phonetischem Vergleich nicht weit!

    Tschüss
    Tiggr (aka Marcus)


    --------------------
    @bout Kites: Colorful Sky - Typo3
    @bout LARP: Orga ohne Namen - Sefrengo
    @bout LARP: LARP-Welt - CakePHP
    @bout Kites: Rodgauer Workshop - Contao
    Go to the top of the page
     
    +Quote Post
    Tiggr
    Beitrag Sun. 9. September 2007, 14:35
    Beitrag #20


    Advanced Member
    *******

    Gruppe: AdvancedMembers
    Beiträge: 386
    Mitglied seit: 12.07.2006
    Mitglieds-Nr.: 136



    Hiho!

    Ich hab mal zum ausprobieren für euch eine Demo-Seite aufgesetzt: http://colorfulsky.co.ohost.de/index.php?idcatside=2

    Tschüss
    Tiggr (aka Marcus)


    --------------------
    @bout Kites: Colorful Sky - Typo3
    @bout LARP: Orga ohne Namen - Sefrengo
    @bout LARP: LARP-Welt - CakePHP
    @bout Kites: Rodgauer Workshop - Contao
    Go to the top of the page
     
    +Quote Post

    2 Seiten V   1 2 >
    Reply to this topicStart new topic
    1 Besucher lesen dieses Thema (Gäste: 1 | Anonyme Besucher: 0)
    0 Mitglieder:

     



    RSS Vereinfachte Darstellung Aktuelles Datum: 28.3.24 - 22:42

    Sefrengo ist ein eingetragenes Markenzeichen und urheberrechtlich geschützt.
    Copyright 2009 Design & Daten, Alle Rechte vorbehalten.