Beiträge von tk1234

  • Kontaktformular will nicht

    Zitat von Emess
    Code
    [Wed Oct 25 19:44:34.926488 2023] [fcgid:warn] [pid 3859936:tid 139954424747776] [client […]] mod_fcgid: stderr: PHP Warning:  Unexpected character in input:  '\\' (ASCII=92) state=1 in […]/php/contact-3.php on line 51, referer: […]

    Gemäß der allwissenden Müllhalde (aka Google) bzw. Stackoverflow liegt das Problem an der verwendeten PHP-Version: PHP 5.2 kennt noch keine Namespaces, stell auf auf eine aktuelle PHP-Version (>= 8.1) um.

  • Kontaktformular will nicht

    Zitat von Emess

    Vielleicht hat jemand ein passendes PHP, das ich einfach über mein HTML und CSS legen kann.

    Damit ist es leider nicht getan: das Formular ist unbedienbar da die einzelnen Felder keine Beschriftung haben - und nein, placeholder-Attribute sind keine Beschriftung!

    Zitat von Emess
    PHP
    $headers = 'From: ' . $_POST["name"] . '<' . $_POST["email"] . '>' . "\r\n" .
    'Reply-To: ' . $_POST["email"] . "\r\n" .
    'X-Mailer: PHP/' . phpversion();

    Keine gute Idee: der Besucher ist idR niemand der über deinen Server Mails verschicken darf - du erhöhst damit das Risiko dass solche Mails als Spam eingestuft werden und u.U. garnicht erst ankommen.

    Zitat
    Code
     mail( "kontakt@ristorante-sicilia-reinheim.de", $_POST['subject'], $_POST['message'], $headers );

    Vergiss mail(), verwende eine Mailerklasse (z.B. PHPMailer) um Mails zu verschicken.

    Zitat

    Das Layout gefällt mir sehr gut nur die Technik macht Probleme.

    Definiere "macht Probleme".

  • Speicherdauer von Session-Cookies – wie wird sie festgelegt?

    Zitat von m.scatello

    Der Inhalt des Warenkorbs wird nicht im Cookie gespeichert, sondern in der Session. Die Session wird zerstört, wenn du den Browser schließt.

    Das ist nicht ganz richtig. Der Warenkorb wird in der Session gespeichert, das stimmt - aber diese wird nicht zerstört wenn der Browser geschlossen wird. Die Sessiondaten liegen (idR in Form einer Textdatei) auf dem Server und werden vom GC (Garbage Collection) regelmäßig aufgeräumt (bei ungünstiger Konfiguration u.U. auch dann wenn der zugehörige Cookie eigentlich noch existiert und die Session noch benötigt würde!). Beim Schließen des Browsers wird lediglich das Cookie gelöscht womit die Session am Server nicht mehr zugeordnet werden kann und bei einem erneuten Besuch der Seite eine neue Session gestartet wird.

    Zitat von Failix

    Ok, danke! Und warum wird die Session zerstört, wenn ich den Browser schließe? Wäre es nicht möglich, das Cookie im Browser sowie die Session auf dem Server länger zu speichern oder ist dies technisch nicht machbar?

    Doch, sowohl Session als auch Cookie lassen sich auch länger speichern (durch Anpassen der Einstellungen session.gc_maxlifetime bzw. session.cookie_lifetime) - als Besucher einer Seite hast du da aber keinen Einfluss. Sessions sind eben so definiert dass sie nur bis zum Schließen des Browsers gültig sind und der Standardwert für cookie_lifetime ist eben 0 (also bis zum Schließen des Browsers).

    Vorsicht, eine längere Laufzeit des Session-Cookies heißt u.U. dass es im Bezug auf die DSGVO in eine andere Kategorie fällt und du die Einwilligung des Besuchers brauchst - für Session-Cookies brauchst du die wohl nicht (keine Rechtsberatung, frag ggf. den Anwalt deines geringsten Misstrauens!).

  • Wie soll ich diesen Fehler beheben?

    Zitat von m.scatello

    Beim Einsatz von SQL-Datenbanken sollte das Abrufen aller Spalten eines Datensatzes per SELECT * vermieden werden. […]

    Völlig richtig, das größere Problem an der Codezeile ist allerdings die fehlende Behandlung des Kontextwechsels, so ist der Code gefährlich! Direkt davor ist ja anscheinend noch klar wie das richtig geht, da werden prepared Statements verwendet (wenn auch das Ergebnis der Abfrage nicht abgeholt wird) …

  • seltsames Verhalten der webseite

    Zitat von nextuser

    Wozu Eingaben & Buttons mit dem input-Tag realisieren, wenn es doch den button-Tag als "richtigen" Button gibt?

    Zumal ein richtiger <button> noch die Vorteile hat dass man die Werte der name-/value-Attribute unabhängig von der Beschriftung des Buttons definieren kann und diese auch nicht nur aus Text bestehen muss. Das Problem hier ist allerdings dass Links und Buttons (egal ob input oder button) nicht verschachtelt werden dürfen, <a><input></a> ist also kein gültiges HTML - aber m.scatello schrieb ja schon dass der Code nach /dev/null verschoben gehört …

  • Quiz mit Javascript erstellt - bitte um Code-Beurteilung

    Zitat von Sempervivum

    So what - inwiefern enthält die Struktur von Failix Redundanzen?

    Die Struktur verletzt die erste Normalform. Ja, aktuell mag es so sein dass es immer vier Antwortmöglichkeiten gibt, trotzdem ist es sinnvoll die Datenbank gleich richtig aufzubauen - auch so Dinge wie eine Suche in den Antworten oder das Auflisten der Fragen samt richtiger Antworten werden dadurch (überhaupt bzw. ohne Verrenkungen) möglich.

  • Quiz mit Javascript erstellt - bitte um Code-Beurteilung

    Zitat von Failix

    Wenn nummerierte Spalten nicht optimal sind, wie soll man die Spalten mit den vier Fragen dann bezeichnen?

    Die Spalte, Singular. in der Antworten-Tabelle gibt es zu jeder Frage vier (bzw. so viele wie es Antwortmöglichkeiten gibt eben) Datensätze wie die Spalte mit den Antworten jetzt genau heißt sei dir überlassen (frag 3 Leute und du bekommst 5 Antworten). Beschäftige dich mit der Normalisierung von Datenbanken, im Beispiel zur zweiten Normalform im Artikel bei Wikipedia sind die CDs quasi deine Fragen und die Lieder die Antworten.

  • Quiz mit Javascript erstellt - bitte um Code-Beurteilung

    Zitat von Failix

    Ist es sinnvoll, die Struktur so anzulegen?

    Nein. Nummerierte Spalten sind idR ein deutlicher Hinweis darauf dass das Datenbankdesign defekt ist. So auch hier: die Antworten gehören in eine extra Tabelle in der dann noch die ID der Frage steht (ggf. eine Spalte mit einem Sortier-Wert wenn die Reihenfolge der Antwortmöglichkeiten festgelegt werden soll). Wo du speicherst welche Antwort richtig ist, hängt etwas davon ab ob es (zukünftig) möglich sein soll dass auch mehr als eine Antwort richtig ist: wenn nur eine richtig ist kannst du sie in der Fragen-Tabelle speichern, sonst in der Antworttabelle.

    Und: Datenbankdesign immer als SQL-Querys (CREATE TABLE für das Design und INSERT für die Daten) posten, nie als Bild - hat auch den Vorteil dass man evtl. falsche Spaltentypen gleich mit erkennt.

  • IF Abfrage alle 3 Stunden ausführen

    Zitat von MarvinTLA

    Habe also den Befehl "crontab -e" genutzt auf meinem Raspberry PI und habe ganz unten folgendes hinzugefügt.

    /1 * * * * root /usr/bin/php /var/www/html/includes/verbindung.php


    Auch nach längerer Wartezeit ist nichts passiert.

    Logisch. Da zum einen ist »/1« als Angabe für die Minuten falsch, vor »/1« muss ein Bereich oder ein »*« stehen - wobei »*/1« zwar richtig, aber wenig sinnvoll ist: »*« macht das gleiche (siehe »man crontab.5«). Zudem gehört das »root« da nicht rein - zum einen soll das ganze sicher nicht als root ausgeführt werden und zum anderen gibt es in der Datei die mit »crontab -e« bearbeitet wird (im Gegensatz zu /etc/crontab) keine Spalten für den Benutzernamen.

  • IF Abfrage alle 3 Stunden ausführen

    Zum Cronjob-Problem hat m.scatello ja schon geschrieben: einfach ein Script unabhängig von den schon existierenden Dateien erstellen (den ersten Punkt im Folgenden beachten!)

    Zitat von MarvinTLA

    In den Dateien createFolder.php und createUser.php steht soweit immer das gleiche drin.

    Sehe ich das richtig? Der Teil zum prüfen der Verbindung ist in beiden Dateien identisch (bis auf den Dateinamen halt?). Wenn du Code durch kopieren von einer Datei in eine andere duplizieren musst, ist das ein deutlicher Hinweis darauf dass du den Code in eine Funktion/Klasse auslagern und die Methode/Funktion in beiden Dateien aufrufen möchtest.

    Zitat von MarvinTLA

    ":datum" => date('d.m.y'),

    Das Datenbankdesign scheint mir defekt zu sein: das ist kein Datumsformat mit dem MySQL was anfangen kann. Der Parameter ist aber überflüssig, NOW() in den Query zu schreiben reicht (Voraussetzung ist natürlich ein korrekter Datentyp was bei dir nicht gegeben scheint).

    Zitat von MarvinTLA

    $passwort = $_POST['passwort'];

    Das umkopieren von Werten aus $_POST usw. war schon immer Unsinn, du kannst bei execute auch direkt die Werte aus $_POST verwenden. Speziell bei der Zeile erhebt sich allerdings noch die Frage: wo kommt $password_gehasht weiter unten dann auf einmal her?

    Zitat von MarvinTLA

    $createFolder = ssh2_exec($connection, "mkdir " . escapeshellarg("/media/Files/" . htmlspecialchars(ucfirst($userData["nachname"])) . "/" . $pfad . "/" . $nameNeu));

    Das htmlspecialchars hierdrin ist Käse, einen Kontextwechsel nach HTML gibt es hier nicht. Und wo kommt $userData auf einmal her? Und wo wird sichergestellt dass in $userData['nachname'] kein ../ steht?