Ankündigung

Einklappen
Keine Ankündigung bisher.

Suchscript PHP Datenbank

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Suchscript PHP Datenbank

    Hallo,
    ich habe hier im Forum ein Tutorial gefunden, wie man eine Datenbank durchsuchen kann. Dieses kam mir nur ein wenig zu kompliziert durch, deshalb wollte ich fragen, ob solch eine Suche auch genauso gut ist:

    PHP-Code:
    <?php
    $keyword 
    "Mustermann";
    $abfrage "SELECT * FROM tabelle WHERE a LIKE '$keyword' OR b LIKE '$keyword' OR c LIKE '$keyword'";
    $ergebnis mysql_query($abfrage)  OR DIE (mysql_error());
    while(
    $row mysql_fetch_object($ergebnis))
       {
       echo 
    "$row->id <br>";
       }
    ?>
    Das Keyword kann natürlich auch per Formular übergeben werden. Was sagt ihr dazu?


  • #2
    auch genauso gut ist
    Genauso gut wie was? Das Beispiel, das nur Du kennst? Und nein - sicher ist es das nicht. Z.B. fehlen bei Dir Verbindungsaufbau, Fehlerverfolgung, Injection-Schutz.

    Die Antwort ist nein.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Wie geht ein Injectionschutz? Hast du nen Link? Fehler habe ich geprüft und Verbindungsaufbau ist im anderen Part des Programmscripts.

      Kommentar


      • #4
        ehm, google.de? - oder sollen wir auch noch für dich googlen?! *g*
        in der boardsuche findest hier übrigens auch passende themen, und im WIKI meine ich steht dazu auch was.

        btw: hast du nikosch sein post überhaupt richtig gelesen und verstanden?

        performancebedingt - je nach größe der tabelle - ist das sowieso nicht der beste weg, immer den LIKE-operator in diesem statement zu benutzen.. (für eine frontend-suche)..

        btw2:
        http://www.php.de/software-design/70...achigkeit.html

        Kommentar


        • #5
          Fehler habe ich geprüft
          DU hast ein OR DIE drin, das gerade mal für den Zeitpunkt der Entwicklung ausreicht.

          Das Keyword kann natürlich auch per Formular übergeben werden
          Naja, bisher eher nicht.
          --

          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


          --

          Kommentar


          • #6
            DU hast ein OR DIE drin, das gerade mal für den Zeitpunkt der Entwicklung ausreicht.
            Was soll man dann machen ? Weil wenn man mal davon ausgeht, dass alle Parameter abgesichert sind, kommt immer ein korektes SQL-Statement zu stande, das (falss der User Schrott eingibt) im schlimmsten Fall ein leeres Ergebnis liefert. Aber dann reagieren ich doch auf das leere Ergebnis, oder soll ich auch auf kaputte SQL-Kommandos reagieren ?
            Und wenn ja: Wie ?
            Signatur:
            PHP-Code:
            $s '0048656c6c6f20576f726c64';
            while(
            $i=substr($s=substr($s,2),0,2))echo"&#x00$i;"

            Kommentar


            • #7
              Zitat von ByStones Beitrag anzeigen
              Was soll man dann machen ? Weil wenn man mal davon ausgeht, dass alle Parameter abgesichert sind, kommt immer ein korektes SQL-Statement zu stande, das (falss der User Schrott eingibt) im schlimmsten Fall ein leeres Ergebnis liefert. Aber dann reagieren ich doch auf das leere Ergebnis, oder soll ich auch auf kaputte SQL-Kommandos reagieren ?
              Und wenn ja: Wie ?
              edit: mist. hab in deinem Beitrag etwas überlesen und weiß nich, ob ich dir mit diesem Ratschlag helfe... egal, ich lasses mal stehen.
              -->
              Wenn der User durch seine Eingaben deine SQL-Queries "kaputtmachen" kann, kann er sie auch manipulieren.
              Und das ist eine Sicherheitslücke die es zu beheben gilt
              Google mal SQL-Injections oder ähnliches, dann verstehst du, was du ändern musst.

              Kommentar


              • #8
                Was soll man dann machen ?
                Exceptions!
                http://hallophp.de

                Kommentar


                • #9
                  Zitat von ByStones Beitrag anzeigen
                  Was soll man dann machen ? Weil wenn man mal davon ausgeht, dass alle Parameter abgesichert sind, kommt immer ein korektes SQL-Statement zu stande, das (falss der User Schrott eingibt) im schlimmsten Fall ein leeres Ergebnis liefert. Aber dann reagieren ich doch auf das leere Ergebnis, oder soll ich auch auf kaputte SQL-Kommandos reagieren ?
                  Und wenn ja: Wie ?
                  Der Query kann nicht nur fehlschlagen weil er fehlerhaft ist. Der Server kann Abstürzen oder ein Depp hat die Datenbankstruktur modifiziert und es fehlt eine Spalte die der Query aber verlangt, Tabellen wurdne umbenannt etc. pp.

                  Da kannst du dann noch so perfekte Queries schreiben....

                  Wenn du z.B. eine Liste von Datensätzen ausgeben willst kannst du einfach auf die Seite schreiben "keine Datensätze gefunden" -> was theoretisch auch nicht stimmt weil es gar nicht geprüft wurde, aber wenn du über eine Session Benutzerdaten aus der DB holen willst, anhand der Session weisst das es dazu Daten geben muss und diese zwingend nötig sind, aber kein DB Result wegen abgekratztem Server bekommst was tust du dann mit deinem "or die"? Im schlimmsten Fall haust du dem Benutzer deiner Anwendung eine SQL Fehlermeldung um die Ohren -> sehr unschön.
                  "Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".

                  Kommentar


                  • #10
                    Im schlimmsten Fall haust du dem Benutzer deiner Anwendung eine SQL Fehlermeldung um die Ohren -> sehr unschön.
                    Oder aber lieferst halbfertiges HTML aus - bei die ist nämlich Schluss mit der Ausgabe.

                    Eigentlich wurde ja schon alles gesagt: Niemand ist vor Fehlern sicher - nicht vor eigenen, nicht vor Sicherheitslücken, nicht von Problemen der Infrastruktur. Ein „kann eigentlich nicht passieren“ ist schon immer eine halbe Garantie zum Applikationsfehler. Das demonstriert Software wie Windows immer wieder eindrucksvoll mit Fehlermeldungen wie „unerwarteter Ausnahmefehler“ oder „should not happen...“.
                    --

                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                    --

                    Kommentar

                    Lädt...
                    X