Beiträge von JR Cologne

Geht mir ähnlich. Habe mich bisher auch noch nicht so wirklich mit dem Thema Frameworks auseinandergesetzt. Bin auch der Meinung, dass das erst geschehen sollte, wenn man das Meiste, was ein Framework einem dann abnimmt, auch selbst beherrschen sollte.

Das bedeutet, Frameworks erst einsetzen, wenn man sich schon ganz gut mit PHP, Datenbanken und Co auskennt. Und dazu gehört auch OOP, wie Stef schon erwähnt hat.

Wenn man dann an dem Punkt angekommen ist, das man vieles Mal selber gemacht hat und sich soweit fit in PHP fühlt, kann man weitergehen und Frameworks einsetzen, um seinen Workflow und seine Anwendungen auf eine neues Level zu heben und professioneller zu arbeiten.

Ich würde das folgendermaßen machen:

So sieht dein Link aus: http://example.com/RegistrationAbschließen.php?email=user@email.com&token=random_token

Die URL sowie die Parameter musst du natürlich entsprechend ändern bzw. werden von deinem Script beim Versand der E-Mail eingefügt.

Anschließend empfängst du die Parameter in der RegistrationAbschließen.php:

<?php
    $email = $_GET['email'];
    $token = $_GET['token'];
?>

Danach geht dann dein noch etwas angepasstes Script weiter mit den ganzen Checks usw. und letztendlich dem Eintrag in der DB.

Ganz klare Antwort: Von Anfang an!

Responsive Webdesign bedeutet nicht nur, dass man möglichst auf feste Höhen und Breiten usw. verzichtet und so ein Layout erstellt, das auf jedes beliebige Gerät reagiert und sich anpasst, sondern insbesondere auch, dass von der Konzeption bis zur Fertigstellung zu jeder Zeit bedacht wird, wie man das Erlebnis des Nutzers auf jedem Gerät möglichst gut gestalten kann.

Responsive Webdesign ist nicht nur dazu gedacht, dass du am Ende der Entwicklung deiner Seite noch ein paar kleine Anpassungen vornimmst, um die Mobile-User nicht total zu verschrecken, sondern erfordert eine komplett neue Herangehensweise und ein neues Denken beim Erstellen von Websites.

Und ja, richtiges Responsive Webdesign ist heutzutage alternativlos, um eine erfolgreiche Website aus dem Boden zu stampfen!

Edit: Ob man sich für Desktop- oder Mobile-First entscheidet, ist hierbei egal und muss anhand der Anforderungen des Projekts getroffen werden.

Das <tfoot> kommt nach dem <tbody>, wenn man nach dem HTML5-Standard agiert. HTML4 hingegen sagt, dass es genau andersherum richtig ist.

So sieht es für mich zumindest aus...

https://developer.mozilla.org/de/docs/Web/HTML/Element/tfoot

Wusste ich auch noch nicht.

Ach, ja. Stimmt. Um :hover und sonstige besondere Zustände anzuzeigen, musst du das erst explizit auswählen. Müsste irgendwo über den CSS-Styles sein...

Schön, dass du eine Lösung gefunden hast.

Beim zweiten Problem kann ich, wie gesagt, ohne mir den Code selber anzuschauen, nicht groß helfen.

Bin gerade im Urlaub und daher nur mobil unterwegs. Kann also selber nicht nachschauen und nur allgemeine Antworten geben:

Gehe auf deine Seite, öffne die Entwicklertools (F12) und wähle dann mit dem "Auswahl-Tool" oben links in der Ecke das entsprechende Element auf der Seite aus oder suche es alternativ in dem HTML-Code. Wenn du es ausgewählt hast, werden dir rechts an der Seite die entsprechenden CSS-Anweisungen aufgelistet. Anschließend suchst du dir die Zeile raus, wo dein Button angesprochen wird und änderst dies deinen Wünschen entsprechend. Für die Hintergrundfarbe z.B. mittels background-color.

Bei dem zweiten Problem kann ich dir so gerade gar nicht helfen...

Das kommt ganz auf dein HTML an.

So können wir nur raten. Brauchen mehr Informationen...

Ich habe das mit dem Server-Query-String noch nie gesehen und vermute, dass da der Fehler liegt. Normalerweise verwendet man nämlich GET.

Kannst du mal ein var_dump für parameter machen?

Und noch was: Warum holst du die E-Mail über die Session? Würde das eher in den Link einbauen, weil sonst muss der User sich wieder komplett neu registrieren, sollte er zwischendurch den Browser schließen.

Entweder ich verstehe dich falsch oder das Problem sollte nach meiner Meinung nicht existieren, wenn du alles richtig implementiert hast...

Würdest du dein Problem mal näher ausführen? Danke.

Du erstellst für jeden User einen eigenen Link-Hash, speicherst den in der DB und sendest dann in der E-Mail den Link inkl. User-ID oder E-Mail und Hash als Parameter, sodass du nach Klick auf den Link weißt, wer gerade versucht sein Account zu bestätigen, und dann entsprechend entscheiden kannst, ob alles erfolgreich funktioniert hat und der User aktiviert werden kann.

Der User wird immer anhand der Session identifiziert in der seine User-ID hinterlegt ist. Du musst also diese beim Login dort speichern.

Sagen wir mal, Tom loggt sich ein. Du speicherst dann seine ID, sagen wir mal 3, in der Session. Anschließend geht er auf die Startseite und will dort was posten. Er schickt das Formular ab. Nun gehst du hin und holst die ID aus der Session und speicherst anschließend seinen Beitrag in der entsprechenden Tabelle, inkl. seiner ID.

Du kannst zu deiner Tabellen mit den Usern eine Spalte namens "active" (oder so) und ein Feld für deinen Token/Hash hinzufügen.

Du gehst dann also bei jeder Registrierung hin, erstellst den Token/Hash, baust den in deinen Link in der E-Mail ein und speicherst ihn in deiner DB.

Bei Klick auf den Link wird der User zu einer Seite von dir weitergeleitet, die bei Richtigkeit des Tokens/Hashes dein active in der DB auf 1 setzt. Somit ist der User erfolgreich registriert. Bei dem Login wird dann eben auch noch abgefragt, ob der Account aktiv ist, sprich ob active = 1.

Gerade mal getestet. Sieht gut aus.

Zitat von Jav

Gegenfrage: Funktioniert es bei dir mit der Hash-Variablen? Dann muss es noch einen Trick geben, und ich lerne gern dazu

Edit:
Ich sehe gerade, du hast das noch garnicht probiert, sonst hättest du das mit dem immer gleichen Hash nicht geschrieben.

Aber danke fürs Gespräch.

Bei mir funktioniert es.

Der "Trick" ist, dass man mit password_hash() den einzigartigen Hash erstellt, diesen in der DB speichert und beim Login dann mit dem Passwort per password_verify() "vergleicht". Wichtig ist dabei, um das nochmal zu wiederholen, dass das Passwort in keinster Weise verändert wird und der richtige Hash aus der DB geholt wird. Viel mehr ist das nicht.

Habe gerade auch nochmal dein Code-Schnipsel getestet. Auch das funktioniert übrigens.

Dadurch, dass du den Hash aus der DB ziehst, stimmt er ja mit dem Hash, der bei der Registrierung erstellt wurde, überein.

Wenn man dann dasselbe Passwort angibt, sollte alles funktionieren. Dabei muss man, wie Cotton schon angemerkt hat, aufpassen, dass man das PW in keinster Weise verändert.

Wenn die $ im Hash als Anfang einer neuen Variable gelten, würde mich sehr wundern.

Wie denkst du denn, würde dann password_verify() eingesetzt werden können, wenn dies immer falsch interpretiert wird? Das Setzen eines konstanten Strings als Hash ist schließlich keine Alternative in einem dynamischen System.

Gut, dann muss vermutlich mal jemand anderes drüber schauen. Ich finde da nichts. Entweder ich bin blind oder es ist zum Verzweifeln merkwürdig.

Vielleicht hat ja @cotton oder so die Tage mal Zeit/Lust drüber zu schauen.

Hm, bist du sicher, dass du das richtige Passwort eingibst?

Lösche deinen aktuellen User nochmal, registriere den neu und versuche dich dann einzuloggen. Und dabei bitte auf die Richtigkeit des Passworts achten.

Gebe mal bitte dein Passwort aus, dass du in password_verify() einführst.

Ansonsten weiß ich immer noch nicht, was genau ausgegeben wird. Bei welchen von den vielen Fehlermeldungen endest du?

Wenn dein PW-Hash richtig aus der DB geholt wird usw. müsste das eigentlich stimmen. Ohne Kontext sieht halt das $fetchRow->password ein wenig merkwürdig aus, aber ich denke mal, da liegt nicht dein Problem. Sonst wäre dir das vermutlich ja schon aufgefallen.

Versuch dir mal alles mögliche auszugeben und dementsprechend genau nachzuvollziehen, was bei dir passiert und wo der Fehler liegt.

Ansonsten müsstest du mal mehr Informationen geben. Was ist dein genaues Problem, gibt es Fehlermeldungen, ganzer Code etc.?

Ganz klarer Fall eines ordentlich indischen Akzents. Könnte mich da immer ablachen, ist mindestens genauso gut wie ein richtig deutscher Akzent.

Also, ja. Teilweise muss man genau hinhören und sich bisschen was dazudichten.