Beiträge von cottton

    :)

    Code
    Warning:  htmlentities(): charset `UTF8' not supported, assuming utf-8 in 

    Müsste jetzt selbst nachsehen, warum. Aber lass das weg.

    Das maskieren von Daten passiert immer bei der Ausgabe,

    Sonst kann es passieren dass Du

    A: bei der Ausgabe nicht maskierst, weil Du meinst, Du hast ja sichere Daten in der db (wovon Du nie ausgehen darfst)

    B: bei der Ausgabe auch noch mal maskierst, und dann doppelt maskierte Sachen raus bekommst (was manchmal echt schwer zu finden sein kann)

    Also trim und länge prüfen, email validieren, und beim Laden der Daten aus der db die Daten so behandeln,

    als ob sie Benutzereingaben sind (was sie auch sind, selbst wenn sie in der db liegen).

    Guck mal hier: http://sandbox.onlinephpfunctions.com/code/4aa2daac9…edcff9b18e91d6c

    Im test läufts.

    Schätze, dass Dir htmlentities reingepfuscht hat.

    $ baucht hier einen String. Aber ohne Klammern bekommt $ die Klasse $myClass.

    Und die Klasse kann nicht als String verwendet werden.

    Mit Klammern wird erst das Ergebnis aus $myClass->getVarName() geholt - was ja dann auto ist.

    Daraus entsteht $auto.

    Aber warum denn das, wenn zwei $$ davor stehen

    Du siehtst das wahrscheinlich immernoch falsch :D

    $$ ist keine einzelne Anweisung o.ä.

    Das sind 2 Sachen die hier passieren:

    erste $ -- hier wird es um eine Variable gehen

    zweite $ -- hier wird es wieder um eine Variable gehen

    Mir ist gerade das Konstanten Bsp eingefallen - hier wird es glaub ich deutlicher:

    PHP
    $auto = 'VW';
    define('VAR_NAME', 'auto');
    echo $VAR_NAME; // Undefined variable: VAR_NAME
    echo ${VAR_NAME}; // VW

    Wie bisher wollen wir die Value von $auto. Der Name der Variable kommt dieses Mal aus der Konstante VAR_NAME.

    Und hier zeigt sich, wie wichtig Klammern sind:

    ohne Klammern geben wir fälschlicher Weise an, eine Variable $VAR_NAME aufzurufen.

    Mit Klammern wird erst die Value aus der Konstante geholt.

    Keine 2 x $$. Das existiert eigentlich gar nicht. :)

    Du könntest das mit array vergleichen:

    Ist jetzt nicht wirklich das gleiche, aber zeigen, dass es halt nur um die value geht, die in der Variable steckt.

    Wenn man diese um die variable schreibt, wird zuerst der Wert in der Variable geladen

    Ja, so kann man es sehen.

    Klammern sollte man immer verwenden. Liest sich besser und Fehler werden vermieden.

    Bsp:

    echo ${$myClass->getVarName()}; holt erst den Namen aus der Klassenmethode, und erstellt dann die variable.

    Und da geht noch mehr: Bedingungen

    PHP
    $auto = 'VW';
    $varName = null;
    echo ${isset($varName) ? $varName : 'auto'}; // VW

    $varName ist nicht gesetzt (NULL).

    Wir wollen eine Variable ausgeben.

    Der Name der Var steckt endweder in $varName, oder es wird "auto" genutzt.

    Man muss das nicht verwenden. Sollte es mal gesehen haben.

    Ich persönlich nutze es öfter mal zB bei Schleifen.

    Bsp

    Warum kommt denn da die Fehlermeldung ? Man greift doch auf den wert vom key method zu. Verstehe ich nicht.

    Weil der syntax nicht stimmt. Bei arrays müssen eben die Klammern genutzt werden :)


    echo "\$b value: '{$b}'\r\n";

    Output: $b value: 'test'

    $$b (besser lesbar ${$b}) bedeutet also $test

    und $test ist nicht definiert.

    Im Grunde sagst Du

    $ ich will eine variable

    deren Name in $b steck.


    Das hier sieht irre aus, ist aber eigtl ganz einfach:

    PHP
    $b = "test";
    $c = "test1";
    $f = "test2";
    $test = 123;
    
    echo "\$b value: '{$b}'\r\n";
    
    echo "\${\$b} value: {${$b}}";

    die $ sind mit Backslash maskiert, um sie ausgeben zu können.

    Warum würde ohne die {} PHP es nicht verstehen ? Verstehe ich nicht.

    Ohne {} bekommst Du einen syntax error.

    Warum ist es da denn wichtig ?

    "Array to string", da $object->$array ausgeführt werden würde.

    Durch die {} wird zuerst die value aus dem array geholt.


    BTW: wähle mal auf PHP.net http://php.net/manual/en/language.variables.variable.php die Sprache "english" aus. Da gibts oft mehr Beispiele.

    EDIT: ich merke gerade wieder, dass ich mit dem neuen Forumeditor nicht klar komme. :(


    Die Klammen () beeinflussen die Reihenfolge von Statements.

    Ablauf an Deinem Bsp $ergebnis = ($a + $b) - $c * $d

    Info: PHP verarbeitet Statements von rechts nach links.

    - zu erst wird c * d ausgeführt

    - das Zwischenergebnis daraus soll von links subtrahiert werden aber -

    - durch die () Klammen wird als nächstes a + v ausgeführt

    - zum Schluss wird rechts von links subtrahiert.

    Zum $_POST -Bsp:

    in dem Bsp sind die Klammern fehlerhaft.

    Fixed:

    PHP
    if(     (         !isset($_POST['test']) && strlen($_POST['test']) === 0
        )     || empty($_POST['test'])
    ){
        echo "Testing";
    }

    empty() macht hier keinen Sinn, irgendwie. Man will ja, dass es gesetzt ist, und länger als 0.

    Also if ( isset($_POST['test']) && strlen($_POST['test']) > 0 ) {}

    Die {} Klammern kann ich nicht erklären. Mir fällt da gerade echt nicht ein, wie man das erklärt :D

    Genutzt werden die jedenfalls oft in Ausgaben - zB HTML.

    PHP
    $person = array();
    $person['name'] = 'cottton';
    echo "In doppelten Anführungszeichen wird Code ausgefürt. Deshalb kann ich meinen Namen einfügen: {$person['name']}";

    Ohne Klammern würde PHP das ganze nicht verstehen.

    Wichtiger werden die Klammern aber bei variablen variablen (http://php.net/manual/de/language.variables.variable.php)

    Oder zB bei Methodenaufruf per variable:

    Ja ich filtere die Daten ja schon bevor sie in die Datenbank kommen. Braucht man da dann unbedingt htmlspecailchars ?

    Ja. Wie gesagt - alle Daten die raus gehen (hier im Bsp zum Browser) gelten als unsicher.

    Probier mal das Bsp mit dem alert. Egal wie das in die db kommen könnte - es kann passieren. Und wenn Du die db Daten dann als sicher ansiehst, hast Du verloren.

    $id = $_POST['hidden']; // -> Session id

    Mach das nicht.

    Man könnte hier per (zB) curl eine POST-Request absenden und jede beliebige SESSION-id mitgeben.

    Besser:

    $id = $_SESSION['id'];

    Wenn ich jetzt per curl einen Beitrag absenden will, muss ich mir die Mühe machen Cookies mitzuschreiben.

    Und ich komme immernoch nicht weiter, weil ich nicht eingeloggt bin.

    Müsste also auch noch den Login per curl durchlaufen.

    Und genau hier bist Du sicher, dass nur ein Authentifizierter User die Möglichkeit hat, einen Beitrag zu posten.


    PHP
    foreach ($fetchAll as $beitraege) {
                                            echo '<article class="userbeitraege">';
                                            echo '<p>Gepostet von <a href="#">' . $beitraege['username'] .'</a></p>';
                                            echo '<p>' . $beitraege['beitrag'] . '</p>';
                                            echo "</article>";
                                        }

    Auch wenn die Daten in Deiner db liegen - es sind Userdaten.

    Nur, weil sie schon in der db sind, heißt das nicht, dass sie sicher sind. Im Prinzip sind auszugebende Daten (egal woher) immer zu maskieren.

    htmlspecialchars() ist neu:

    Code
    foreach ($fetchAll as $beitraege) {
                                            echo '<article class="userbeitraege">';
                                            echo '<p>Gepostet von <a href="#">' . htmlspecialchars($beitraege['username']) .'</a></p>';
                                            echo '<p>' . htmlspecialchars($beitraege['beitrag']) . '</p>';
                                            echo "</article>";
                                        }

    Du kannst das mal testen, in dem Du das hier mal manuell in deine db schreibst (zB ins feld 'beitrag'): <script>alert('ich hab mich ion deine db geschlichen :p')</script>

    Ohne htmlspecialchars wird der Browser den JS code ausführen.


    Um den Beitrag, der gerade gespeichert wurde, mit in die Liste zu bekommen, musst Du die Beiträge erst nach der Beitragerstellung laden.

    - lade User aus der db

    - speichere neuen Beitrag des Users

    - lade alle Beiträge


    Zur Tabelle:

    Es gibt viele Wege. Vorallem auch kompliziertere zB mit Versionen des Beitrags. Aber das würde hier den Rahmen sprengen.

    Grundlegendes sollte aber immer dabei sein:

    - wer (ident - user id)

    - was (beitrag)

    - wann (datum|created_at)

    Später kannst Du das erweitern. Zb wenn Der User seinen Beitrag editieren kann|darf, dann erweiterst Du die tabelle um updated_at.

    Evtl willst Du als Admin auch mal Beiträge entfernen. Dann köntest Du ein Feld is_active (0 oder 1) hinzufügen.

    Usw.

    Eine Session ist nicht für alle da.

    Jeder User hat seine eigene.

    Grober Ablauf:

    - Script startet (zB Loginseite)

    - Du nutzt als erstes sesstion_start(); im Script

    - PHP erstellt (wenn nicht schon vorhanden) eine Datei auf dem Server (Pfad bekommst Du zB per session_save_path())

    - User loggt sich ein und Du setzt $_SESSION[id] = {user_id}

    - PHP schreib die Daten in die Datei auf dem Server

    - Scriptende

    Eine Session ist alse eigentlich eine Datei auf dem Server.

    Die Zuordnung passiert zB per Browsercookie.

    Ich tippe immernoch auf das erste Script.

    Hier -

    PHP
    session_start();
    //linkhash aus der url
    $parameter = isset($_SERVER['QUERY_STRING']) ? $_SERVER['QUERY_STRING'] : null ;
    var_dump($parameter);
    var_dump($_SESSION['email']); //hier kommt NULL raus

    schreibst Du, dass bei der Session "email" NULL raus kommt.

    Dann behaupte ich mal, dass im ersten Script $email den Wert NULL hat.

    Jedenfalls wäre das der nächste Schritt, den ich überprüfen würde.

    Schätze der Fehler liegt im ersten Script - session wird wohl nicht gesetzt.

    Teste mal dort: