Hallo Forum,
Ich habe das Problem, dass im BE, da wo die FE-User angezeigt und angelegt werden, die Passwörter sichtbar sind. (Ich habe davon ein Bild gemacht: http://test01.ever-growing.de/index.jpg )
Kann man es irgendwie deichseln, dass die Passwörter nicht angezeigt werden oder maskiert werden, z.B. mit Sternchen?
Vielen Dank und viele Grüße
Konstantin
Kein Ahnung, ob noch aktuell, aber wie wäre es, wenn du die Passwörter als MD5 speicherst?
LG - Simon
sobi555 schriebKein Ahnung, ob noch aktuell, aber wie wäre es, wenn du die Passwörter als MD5 speicherst?
LG - Simon
Das ist sicher noch aktuell, da meines Wissens nach sr_feuser_register in der Version 2.5.7 einen Bug hat, der eine erfolgreiche Verschlüsselung verhindert.
Weiss da irgendwer was Neues dazu?
herzliche Grüße
Jürgen
jayes69 schriebda irgendwer was Neues dazu?
Also, ich habe heute Abend die MD5 Extension "auseinandergenommen" und am Ende festgestellt, dass es doch geht... Werde es die Tage noch mal ausführlicher testen und dir dann bescheid geben. Dann schauen wir mal, ob wir den Fehler bei dir finden, denn bei mir klappt es (aus unerklärlichen Gründen...)
LG - Simon
Bei mir funktioniert es trotz der Fehlermeldung:
The running PHP version (5.2.1) is higher than allowed (5.0.9)
Ignore this version requirement
The running TYPO3 version (4.1.2) is higher than allowed (3.8.4)
Ignore this version requirement
Ein paar wichtige Punkte:
Diese Funktion (aus der Datei: class.tx_kbmd5fepw_newloginbox.php) muss auf der Seite vorhanden sein:
<script type="text/javascript">
/*<![CDATA[*/
<!--
function superchallenge_pass(form) {
var pass = form.pass.value;
if (pass) {
var enc_pass = MD5(pass);
var str = form.user.value+":"+enc_pass+":"+form.challenge.value;
form.pass.value = MD5(str);
//alert(str);
return true;
} else {
return false;
}
}
// -->
/*]]>*/
</script>
Ist nicht zwingend der Fall, dass man es selber einbauen muss, doch wenn man selber ein Login erstellt hat um es zb. in der Navigation stylevoll einzubauen fehlt die Fuktion. - Diese Funktion muss beim absenden des Formulars aufgerufen werden. Also:
onSubmit="superchallenge_pass(this); return true;"
Genau so wie folgendes Feld vorhanden sein muss:
<input type="hidden" name="challenge" value="7e0421639e21af9b29f698d5012a726f">
Dieser value muss sich bei jedem Aufruf ändern. Sprich es muss der md5(time()); wiedergegeben werden. Nur da ist meine Frage, wie ich das einbaue und zwar über TS?
Gut, die Datei die dann den neu erzeugten MD5 Wert überprüft lautet: class.tx_kbmd5fepw_sv1.php
Hier kann man ggf. überprüfen (per echo), was denn "ankommt".
Soweit meine "Forschungsergebnisse" mit dem Resultat, dass es funktioniert. :-)
Abschließend meine Frage, wie ich den MD5 Wert der Zeit über TS bekomme und wo es denn bei dir nicht läuft...?
LG - Simon
sobi555 schriebAbschließend meine Frage, wie ich den MD5 Wert der Zeit über TS bekomme und wo es denn bei dir nicht läuft...?
LG - Simon
Hallo Simon,
da hast Du Dir ne Menge Arbeit gemacht, Respekt!
Mein Problem (dessen Lösung ich gestern in ner 10h Sitzung) deutlich näher gekommen bin sieht wie folgt aus:
Anforderung:
In einem geschlossenen Forum sollen Username und Passwort vom System generiert und das PW verschlüsselt in fe_users hinterlegt werden.
Workflow:
User registriert sich auf der Seite. Bekommt Bestätigungs-Anfrage-eMail, die er bestätigt. Danach wird die Anfrage zum Admin Review weitergeleitet. Nach freischaltung durch den Admin ist der Account aktiv.
Problem:
a) zuerst mal funktioniert PW-Verschlüsselung von GENERIERTEN Passwörtern mittels kbmd5fepw nicht mit sr_feuser_register 2.5.7 (und 2.5.8-).
da fehlt eine Funktion die diesen Fall bearbeitet in model/class.tx_srfeuserregister_data.php (der code steht bei mir in den Zeilen 795 und 838 - Danke Xandi für deine Hilfe! wer das Problem hat kann bei mir gerne Beispielcode bekommen)
D.h. generierte PWs werden in der aktuellen Version schlicht nicht verschlüsselt
b) Sobald generierte PWs verschlüsselt werden, stellt sich die Frage, WIE diese in obigem Workflow zum User kommen. In meiner Variante wurden ab diesem Zeitpunkt nur noch MD5-Hashes verschickt. Mit denen kann man sich leider nicht einloggen.
Der Zeitpunkt des Versands der Zugangsdaten muss also auf einen Zeitpunkt VOR der Verschlüsselung verlegt werden, während dessen man das Origrinal-erzeugte-PW noch im Zugriff hat.
Es ist mir mit Hilfe auch noch gelungen die passende Variable ###FIELD_username### (thx again Xandi) zu finden und in tx_srfeuserregister_pi1_css_tmpl.html an der Stelle ###EMAIL_TEMPLATE_SETFIXED_CREATE_REVIEW### einzusetzen.
Damit kann das PW, vor der Freischaltung durch den Admin, im Klartext versendet werden.
Die eingentlich für die Übermittlung der Benutzerdaten vorgesehen Mail enthält dann lediglich das verschlüsselte DB Feld.
Der darauf befindlich Link (samt Credentials) geht ins Leere. Da dabei der MD5-Hash nochmals verschlüsselt ans TYPO3 geschickt wird.
c) EDIT Profile etc.
Nachdem diese Hürden genommen waren, verweigerte sr_feuser_register seinen Dienst bei der Editierung des Profils. Konkret konnte man zwar Daten eintragen, diese wurden aber grundsätzlich nicht verspeichert und die Preview Seite erschien ebenfalls nicht. Fehlermeldungen waren ebenfalls Fehlanzeige.
Nachdem ich an ca. 20 Stellen echos untergebracht hatte, war klar, dass sich sr_feuser_reg an im Template fehlenden PWs stösst. Nachdem diese dort ebenfalls untergebracht waren. Scheint die Sache nun zu funktionieren.
Allerdings gibt es noch folgende
offenen Probleme:
1.) Was passiert wenn jemand sein PW vergisst? Welches, neu generierte, PW wird denn dann an ihn verschickt?
2.) wie kann man den Versand von Login und PW wieder ans Ende des Workflows bekommen, damit die User nicht bereits VOR der Freischaltung durch den Admin Zugangsdaten in Händen halten müssen.
soviel für den Augenblick
herzliche Grüße
Jürgen
hi,
is wohl ein wenig spät, aber vllt hilfts dir ja noch.
ad 1.: das generierte pw ist natürlich random und nur der user bekommt den klartext gemailt. er ist ja auch der einzige, den es was angeht..
ad 2.: hätte es auch gern so wie du, bin aber von der idee den klartext, welcher ja am anfang noch verfügbar ist, in eine tabelle zu speichern bis zur mail nach admin approve nicht so ganz überzeugt. wobei es reizvoll wäre, dem user sein passwort erst zu zeigen, wenn er die loginbox sieht nach dem klick auf den link in der letzten bestätigungsmail (ja, admin mag dich, klick hier). dann würde das pw nicht unsicher vermailt werden. zumindest wenn mit ssl-login.
deshalb hab ich das als "missing feature" in den bugtracker gepostet.
andere sache: hat wer ne lösung dafür, dass sr_feuser_register 2.5.8 mit kb_md5fepw auf eben dieser loginseite, welche man nach dem klick auf die letze gestätigungsmail sieht, nicht geht?
ich weiss woran es liegt, habs aber noch nicht gelöst. der challenge-hash wird vom php zwar ins hidden-field geschrieben, aber nicht in die challenge-tabelle. deshalb vergleicht das skript den ankommenden hash bei loginversuch mit dem, der in verbindung mit dem letzten in der challenge-tabelle steht und meckert. aber wie gesagt, ich hab dafür noch keine lösung.
desweiteren haben sich bei mir schon user beschwert, weil sie ohne javascript ned reinkommen. weisst du, ob es einen fallback auf klartextübertragung und php-superchallenge bereits gibt?
sonst versuche ich mal den freien anteil meiner zeit zu erhöhen und sowas zu machen.
schönen sonntag!