Beiträge von cottton

    mich stört das weniger. Wenn ichs weiß, kann ichs ja sagen.
    Find ich sinnvoller als wenn Du ewig in google suchst um dann auf ne Seite zu kommen wo jemand die Frage stellt
    und als Antwort steht da "google doch".
    Solche Threads hasse ich. Kommt gleich nach "kann geschlossen werden, ich habs hinbekommen" ... und schreibt nicht wie :D

    Das greift bei allem, was da in der db rumlungert.
    Komisch wirds bei den verschiedenen Zeichenstandards ... bin da auch noch nicht weit, aber
    es gibt wohl verschiedenste Sortierungen bei a und ä und ss und ß ... ect.
    Aber im Normalfall braucht man das nicht. Ob der Benutzer mit ä "Erster" ist oder der mit a ... :D
    Kann mir aber vorstellen, dass es bei statistischen Auswertungen einer Tabelle Kopfschmerzen macht :D

    die e-mag die du bekommst reicht nicht aus.
    da steht ein code 0000, aber sonst nix.
    sieht mir danach aus, als wenn die func für die e-msgs nicht macht was sie soll.

    am besten immer die daten so nennen, wie sie genannt wurde:
    SQLSTATE(...)
    Driver code -- der wird hier wohl 0000 sein
    Driver msg

    mach mal ein
    print_r($SQL['ipbldel']['stmt']->errorInfo()); direkt vor generate_query_ErrorMessage()

    Das liegt daran, dass kein Fehler/Warung ect aufgetreten ist.
    Daran hab ich garnicht gedacht :D Muss ich mal angucken ... und ändern.

    Wenn Du nen Fehler provozierst, dann läuft alles, wie es soll:

    PHP
    echo array().'<br>'; # muss einen Fehler schmeissen, weill man ein array nicht verketten kann, und auch nicht echo-en kann
    echo error_get_last_str(); # daher "findet" die func den "last" error
    
    
    
    
    // ausgabe:
    // Notice: Array to string conversion in C:\xampp\htdocs\...
    // Array
    // E_NOTICE: Array to string conversion in C:\xampp\htdocs...


    EDIT:
    Hatte nen stupiden Fehler drin :D

    PHP
    return ($e=error_get_last()) # wenn php function error_get_last() was zurückgibt 
            ?FriendlyErrorType($e['type']).': '.$e['message'].' in '.$e['file'].' on line '.$e['line'] # dann mach n friendly string draus
            :implode(', ',error_get_last() # sonst implode NULL  :D lol, fail
        );

    so isses richtig:


    edit: schon wieder schusselfehler :D

    implode rec. - nein.
    Würde aber an der stelle, wo du ->errorInfo() ausliest, den String zusammenstellen.
    Am besten (da immer wieder mal gebraucht wird) in einer eigenen func/methode.

    Zu errorInfo():
    http://www.php.net/manual/en/pdo.errorinfo.php

    Zitat


    Element Information
    0 SQLSTATE error code (a five characters alphanumeric identifier defined in the ANSI SQL standard).
    1 Driver-specific error code.
    2 Driver-specific error message.


    was Du brauchst ist [0] und [2] mMn.
    Ich glaube [1] ist/war oft leer. Kann mich aber irren.

    Ich hatte letztens schon mal geposted, was ich nutze:

    PHP
    $err_str = '(SQLSTATE: '.$err_info[0].') '.( 
            (empty($err_info[2])) # wenn ebene [2] leer
                ?error_get_last_str() # dann get last error
                :$err_info[2] # sonst nimm ebene [2]
        ).' -- Query: '.$SQL['ipblock']['query']; # und die query anhaengen


    manchmal war/ist die ebene [2] leer. Daher per error_get_last_str() den letzten error geholt.
    Man kann natürlich auch:

    PHP
    $err_info = $SQL['ipblock']['stmt']->errorInfo();
        echo implode(', ',$err_info);


    Aber dann hast Du keine Bezeichnungen.

    Also noch mal übersichtlicher:

    edit:
    sorry - vergessen: die func "error_get_last_str" ist ja nicht vordefiniert :D
    hier is sie:

    implode wuerd ich sagen.

    PHP
    '<br>'.implode('<br>', $SYS['conf']['db']['message']).'<br>'

    oh, jetzt haste editiert ... mom ... lesen :D

    Warum global auf einmal?
    Wenn die function in der gleichen Klasse ist, dann kannste doch $this->SYS nutzen oO?

    Zu dem message array:
    wenn Du dort e-msgs sammelst, dann immer so, dass Du eine "Variante" erwarten kannst.
    Also nicht einmal ein String, oder manchmal ein Array. Dann besser immer ein Array.
    Auch wenn Du im code weißt, dass es nur eine msg wird.
    Dann besser [] = array($single_msg)
    Denn dann kannst Du immer erwarten, dass es ein Array ist.

    und dann halt wie oben schon gesagt: implode()

    und warum schickst Du alle vars in das SYS-Array ? Sogar i ?

    Loesung: http://stackoverflow.com/questions/2068…ectories-in-php
    PSR-0: http://petermoulding.com/php/psr#psr-0

    Jetzt versteh ich auch was ich da in den anderen Frameworks gelesen hab. Die nutzen diese oder eine aehnliche Methode =)
    (Voraussetzung: Verstaendnis/Nutzung von namespace (siehe php.net))

    EDIT: was mir aber daran nicht gefaellt ist, dass man überall den namespace direkt angeben muss.
    Ich kann also nicht in der config.php den Pfad INC definieren und
    namespace INC;
    nutzen.

    Daher muss bei jeder Pfadaenderung der namespace in den Files geaendert werden -.-


    EDIT2: weg mit namespace und her mit der neuen Idee :D
    Wie gesagt - mit der psr-0 methode(?) muss man namespace nutzen. Und namespace kann sinnvoll sein, kann aber auch nerven.
    Und ich fang definitiv nicht an in jedes File den namespace manuell zu setzen. Dynamisch scheint namespace (das Setzen des namespace ...;) ja nicht nutzbar.

    Da ja mein Loader sowieso so aufgebaut war, dass er sich bestimmte Verzeichnisse krallt, war die Aenderung recht einfach.
    Was mach der Loader?
    - lade alle Dateien von Verzeichnis X
    - registriere alle Dateien von Verzeichnis Y

    Bei den Klassen wird also nichts geladen, sondern gemerkt wo was liegt.
    Wenn dann mal ne Klasse ueber autoload gesucht wird, wird in der Liste gesucht.

    Darauf gekommen bin ich, weil die variante mit namespace aehnlich funktioniert - nur halt mit den Pfadangaben im namespace ...
    Nur gefaellt mir meine Variante besser, denn ich brauche keine Pfade manuell platzieren, der Hauptpfad ist einmal in der config.php hinterlegt,
    und ueber die Loader::_load() kann ich die (wenn man es so nennen will) "Pfad-whitelist" jederzeit anpassen =)

    Hier mal der code:

    inverted injections sind injections hintenrum :D
    Wollte das mal testen, dann aber vergessen.

    Finde gerade nix im Netz, aber das Prinzip ist (nicht wie angenommen in meinem Post vorher),
    dass (wie auch immer) ein String in die db komme wie zB:

    Zitat


    alert('hallo'); -- irgendwas ganz boeses :D


    Wenn man mit den db-Daten jetzt eine vorgefertigte Form ausgibt, und die Daten nicht maskiert (htmlspecialchars zB),
    dann wird das ausgeführt - hintenrum.

    Das war allerdings keine SQL-Injection.
    Bei der muesste man wissen, wie das Script arbeitet.
    Man bekommt einen String like

    Zitat


    meinname', `admin` = 1; --
    # halt irgend ne sql-injection


    von der db in den Namen des Benutzers zurueck. Der String kam auf irgend einem ungefilterten Weg in die db.
    Beim (ver-)arbeiten mit dem Datensatz will das Script nu irgendwas updaten
    und der coder hat nur $_POST vars maskiert -- er geht also davon aus, dass hier nix passieren kann:

    Zitat


    "
    UPDATE db.tbl
    SET name = '".$dievar."'
    WEHRE name = '".$dievar."'
    "


    und dabei ensteht das hier:

    Zitat


    "
    UPDATE db.tbl
    SET name = 'meinname', `admin` = 1; -- '
    WEHRE name = 'meinname', `admin` = 1; -- '
    "


    Es gibt sicher bessere Bsp. Ist aber bissl Kopffasching ;D

    Geht doch =)

    Den Fehler "Fatal error: Call to undefined function sqlInfo() in .. on line 243" bekomme ich nicht. Sehe auch nirgends eine function sqlinfo() genutzt oO?
    Aber hier stimmt was nicht:

    btw: Du musst noch einen evtl Fehler bei ->execute abfangen:

    Für die db - ja.
    Im anderen Thread hatte ich das mit den ->prepare und ->execure geposted.
    Wenn Du die PDO nutzt, und immer Platzhalter verwendest, dann ist eine Sql-Injection nicht möglich.

    http://de3.php.net/pdo.prepared-statements

    Zitat


    Wenn eine Anwendung ausschließlich Prepared Statements benutzt, kann sich der Entwickler sicher sein, dass keine SQL-Injection auftreten wird. (Wenn aber trotzdem andere Teile der Abfrage aus nicht zuverlässigen Eingaben generiert werden, ist dies immer noch möglich.)


    Du musst allerdings (sowieso) aufpassen, was auf welchem Weg in die db kommt. Basiii hatte mir das mal gesagt: inverted(glaub ich) injections.
    Aber das läuft so weit ich weiß nicht mit normalen Sql-Anweisungen. Da müsste schon was ausgefallenes her.

    Das geht auch =)
    BTW: Du nutzt die PDO, dann aber keine Daten direkt in die Query!

    PHP
    // auch wenn es die SESSION ist - beim nächsten mal vergisst du iwas und nutzt POST ect in der query.
    $_SESSION['user']['ip'] = "' AND `ip` = 'nicht vorhanden; --'";
    $dbconnect->query("SELECT * FROM `blockedip` WHERE `ip` = '".$_SESSION['user']['ip']."';");


    Nutze besser ->prepare und ->execute
    http://www.php.net/manual/de/pdo.query.php

    Muss ja beides (aussen und innen) anzeigen, denn Du verkettest ja Drinnen:

    PHP
    $this->SYS['conf']['db']['message'] /*die msg ist*/ = 
        $this->SYS['conf']['db']['message'] /*die msg*/   .   /*und*/"  || ".$e->getMessage();


    :D

    hier mal n test ohne der Verkettung. Dafür als array:

    zum 2. Fehler:

    PHP
    $sql['ipblock']['rows']


    Daran liegts.
    $dbconnect ist sicherlich ein Objekt von PDO.
    Daher:

    PHP
    $sql['ipblock'] = $dbconnect->query("SELECT * FROM `blockedip` WHERE `ip` = '".$_SESSION['user']['ip']."';");
    // PDO::query — Executes an SQL statement, returning a result set as a PDOStatement object


    Also $sql['ipblock'] ist jetzt ein obkect. Du kannst also keine Array-Ebene reinquetschen =)
    Besser ne temp-var:

    PHP
    $query = $dbconnect->query("SELECT * FROM `blockedip` WHERE `ip` = '".$_SESSION['user']['ip']."';");