Entwickler Version
Bitte testen Sie es immer vor dem Stellen einer Frage auch mit der aktuellen Entwicklerversion.
| Autor | |
| 14-02-08 09:50:39 | Prüfen von Eingabe |
|
Steffi Meissner |
Hallo, ich habe mir eine Extension geschrieben, die mir neue Felder zur sr_feuser_register hinzufügt. Soweit ja kein Problem. Nun würde ich gerne die Eingabe eines Feldes überprüfen lassen. In das Feld muss immer XY1957 eingetragen werden. Die Zahl 1957 darf im Bereich zwischen 1950 und 2050 liegen... Könnte mir da jemand einen Tipp geben, wie ich das per evalValue prüfen? Würde mich freuen. Liebe Grüße Steffi |
| 14-02-08 14:21:09 | Datumsbereich |
|
Franz Holzinger |
Wenn als Datum nur X.Y.1950 - X.Y.2050 möglich sein soll, so gibt es im Moment keine solche Prüfmöglichkeit über sr_feuser_register. Der Code müsste dafür noch erweitert werden. Derzeit wird auf http://de.php.net/manual/en/function.checkdate.php zurückgegriffen. Hier müsste zusätzlich eine Werteprüfung der Jahreszahlen eingebaut werden. |
| 14-02-08 16:00:21 | ok |
|
Steffi Meissner |
Hallo Franz, vielen Dank für deine Antwort. Und wie sieht es aus, wenn nur XYirgendeineZahl geschrieben werden darf? Also XY oder YX + irgendeine Zahl darf eingetragen werden. Gibt es hier bereits die Möglichkeit für? Wenn nicht stellt sich mir natürlich die nächste Frage: Muss der Code direkt in sr_feuser_register einfließen? Wenn ja, weißt du vielleicht auch an welcher Stelle bzw. Datei? Oder muss ich gar eine eigene Prüfunktion in meine Extension mit der Felderweiterung einbauen? Also die Prüfung an sich in PHP bekomm ich hin. NUr weiß ich noch nicht genau wohin damit... Liebe Grüße Steffi PS: Verzeih bitte mein Fragenfeuer 
|
| 14-02-08 16:45:52 | XY |
|
Franz Holzinger |
Ich weiß nicht, was XY sein soll. Sind das Tag und Monatsangaben? Wenn nicht, dann wäre das eher als einfacher Textstring denn als Datum aufzufassen. |
| 15-02-08 13:10:48 | XY |
|
Steffi Meissner |
es soll entweder WS oder SS eingetragen werden können. Das Problem war, dass es bis heute morgen noch nicht feststand, was da rein soll... Liebe Grüße Steffi |
| 15-02-08 13:34:35 | etwas eigenes |
|
Franz Holzinger |
Eine solche Prüfmöglichkeit gibt es momentan nicht. Vielleicht sollte man die Extension sr_feuser_register über Hooks erweiterbar machen, damit jeder seine eigenen spezifischen Prüffunktionen in PHP schreiben kann. Oder für Spezialisten regulärer Ausdrücke könnte ich einen neuen Prüftyp regexp einfügen. Als Datum ist ein XY1234 jedenfalls nicht mehr erkennbar. Grüße Franz |
| 15-02-08 16:39:28 | ok |
|
Steffi Meissner |
Hallo Franz, nun gut. das ist an sich, denke ich ne Möglichkeit, wenn man mal über eine prinzipielle Erweiterung der EXT nachdenkt... Muss aber momentan nicht speziell für mich sein Ich werde mir mal eine Möglichkeit ausdenken. Wenn mir etwas einfällt, stelle ich dir dann das Ganze per Mail zur Verfügung, ja? Danke für deine Hilfe Liebe Grüße Steffi |
| 2-03-08 23:30:36 | Eigene Pfüffunktionen per Hook - Daumen hoch |
|
Dirk Weise |
Hallo Franz, ich habe schon eine Weile gesucht, wie eigene Prüfungsmöglichkeiten zu integrieren sind. Durch die bestehenden Hooks wurde ich in die Irre geleitet, da ich dachte eine Überprüfung sei durch registrationProcess_beforeConfirmCreate möglich. Nach weiterer Recherche habe ich bisher nur eine einzige, aber nicht sonderlich elegante Lösung gefunden: http://www.typo3.net/forum/list/list_post//70464/#pid264856 Um das Problem zu lösen, bräuchte man einen Hook der die Möglichkeit bietet, Fehlermeldungen für einzelne Felder hinzuzufügen, die dann wiederum dafür sorgen, daß das Formular im Eingabemodus bleibt. Vielleicht fügt man den noch vor der eingebauten Überprüfung ein. Dies ermöglicht durch Änderung der Konfiguration, Felder dynamisch required o.ä. setzen und so auf die bestehenden Prüfroutinen zurückzugreifen. Ich habe jetzt mal etwas gegraben: Das wäre also in der class.tx_srfeuserregister_data.php in der Funktion evalValues vor Prüfung der required Felder. Mitgeben müßte man $dataArray, $this->conf und die Möglichkeit (übersetzte) Fehlermeldungen zu ergänzen. Wenig elegant wäre es auch hier einfach $this zu übergeben. Vielleicht lagert man den kompletten Code zur Fehlerprüfung in eine eigene Klasse aus... Leider kenne ich mich noch zu wenig mit TYPO3 aus, um einen Patch anzubieten, der den hier üblichen Pattern entspräche. Eine eingebauter Prüftyp regexp wäre sicher ebenfalls sinnvoll. Schöne Grüße dirk |
| 1-08-08 16:03:54 | Plausibilität von Eingaben |
|
Roland Fuhrer |
Hallo Franz, Bin nun seit Tagen daran die Überprüfung der Eingaben einzurichten. Es kann ja nicht sein, dass sich jemand mit irgend welchem Stuss als Vorname, Name oder Username registrieren darf. Schon die Validierung der Email, welche in sr_feuser_register von typo3 core übernommen wird, ist für mich zu lau. Da wird bolss getestet ob ein @ vorhanden ist. Was vorher und/oder nachher eingegeben wird, ist wurst. Mangels Kenntnisse von typo3 habe ich kurzerkand die class.t3lib_div angepasst, wo dann auch die checkMail Funktion zugreift. Mein etwas konservativer Code: public static function validEmail($email) { // core function of TRYPO3; for me just to less restrictive //$email = trim ($email); //if (strpos($email,' ') !== false) { // return false; //} //return ereg('^[A-Za-z0-9\._-]+[@][A-Za-z0-9\._-]+[\.].[A-Za-z0-9]+$',$email) ? TRUE : FALSE; // this one taken from Joomla; has a bit more conservative validation settings // Split the email into a local and domain $atIndex = strrpos($email, "@"); $domain = substr($email, $atIndex+1); $local = substr($email, 0, $atIndex); // Check Length of domain $domainLen = strlen($domain); if ($domainLen < 1 || $domainLen > 255) { return false; } // Check the local address // Joomla is a bit more conservative about what constitutes a "legal" address, that is, A-Za-z0-9!#$%&\'*+/=?^_`{|}~- //$allowed = 'A-Za-z0-9!#&*+=?_-'; // I'm even more conservative about what constitutes a "legal" address, that is, A-Za-z0-9_-`{|}~- $allowed = 'A-Za-z0-9_-'; $regex = "/^[$allowed][\.$allowed]{0,63}$/"; if ( ! preg_match($regex, $local) ) { return false; } // No problem if the domain looks like an IP address, ish $regex = '/^[0-9\.]+$/'; if ( preg_match($regex, $domain)) { return true; } // Check Lengths $localLen = strlen($local); if ($localLen < 1 || $localLen > 64) { return false; } // Check the domain $domain_array = explode(".", $domain); $regex = '/^[A-Za-z0-9-]{0,63}$/'; foreach ($domain_array as $domain ) { // Must be something if ( ! $domain ) { return false; } // Check for invalid characters if ( ! preg_match($regex, $domain) ) { return false; } // Check for a dash at the beginning of the domain if ( strpos($domain, '-' ) === 0 ) { return false; } // Check for a dash at the end of the domain $length = strlen($domain) -1; if ( strpos($domain, '-', $length ) === $length ) { return false; } } return true; } Sorry für all die Puristen. Nun möchte ich auch die anderen Eingaben auf Plausibilität überprüfen. Ein Vorname mit Sonderzeichen muss doch gar nicht erst auf die Reise geschickt werden. Da muss die Plausibilität, meiner Meinung nach, überprüft werden. Die parseValues lassen dabei sehr wenig Spielraum. Entweder alpha, num, etc... Wo und vor allem wie kann ich die Regular Expressions nach meinem Gusto editieren? Ich kenne mich ein wenig mit den Regex aus, könnte auch etwas beisteuern zu einer Lösung. Muss einfach wissen wo ich ansetzen muss. Herzlichst grüsst Roland |
| 1-08-08 22:25:05 | Eingabeüberprüfung |
|
Dirk Weise |
Moin Roland, nachdem ich früher auch alles und jedes Detail überprüfen wollte bin ich inzwischen davon geheilt. E-Mail-Adresse: es gibt Umlaut-Domains! Warum diese Leute aussperren? Oder lieber für jede Top-Level-Domain separat auf erlaubte Zeichen prüfen? (http://de.wikipedia.org/wiki/Internationalizing_Domain_Names_in_Applications#Zeichens.C3.A4tze) Namen mit Sonderzeichen: Andere Sprachen, andere Zeichen. Spanier oder Portugiesen, haben lustige zusätzliche Zeichen in ihren Namen, Franzosen Akzente, ... Warum diese Leute zu einer falschen Schreibweise zwingen, wenn es anders geht... TYPO3 bietet demnächst UTF8 als Standard ... meine 2 Pfennig... ;) Schöne Grüße DIRK |
| 22-08-08 08:24:01 | eigene eval Funktion |
|
Franz Holzinger |
Wer es benötigt, kann (ab Version 2.5.17 lauffähig) mit folgendem Setup seine eigene evalFunc schreiben: plugin.tx_srfeuserregister_pi1 { evalFunc = user_myEvalClass->user_validate } Es ist egal, ob eine Email mit oder ohne Umlaute, beides wird in der einen oder anderen Umgebung notwendig sein. Man könnte durchaus ein 'emailold' einführen für Domänen ohne Umlaute und Sonderzeichen. Es gibt ja andere Programme, die auf fe_users aufsetzen und nicht mit Umlauten umgehen können. Die sr_feuser_register ist hierfür vermutlich auch noch nicht getestet worden. Die parseValues dienen zum automatischen Ersetzen von unerwünschten Zeichen, was den Anwender verwirren könnte. Roland, du kannst es in der Datei model/class.tx_srfeuserregister_data.php um weitere evalTypen erweitern. Sende uns hier einen Link auf eine Patch-Datei und wir können es hier besprechen. Grüße Franz |
| < Zurück zum Forum | |