(v=pK4bLMd0avU) GET Parameter von Youtube

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

  • (v=pK4bLMd0avU) GET Parameter von Youtube

    Also ich sehe sowas immer Häufiger bei größeren Portalen.

    Sie übergeben immer mehr Alpabetische Zeichen anstelle von reinen IDs. Warum?

    Wandeln die das wieder um, bevor die den Eintrag aus der DB ermitteln oder heißen auch so die Einträge in den Tabellen?


    Ich finde sowas schon gut, denn wenn man nur Zahlen verwendet denn hat man nur 10 Möglichkeiten für eine Stelle. Nimmt man noch das Alphabet dazu, hätte man über 30 Möglichkeiten und bei mehren Stellen summiert sich das ja. Das heißt, die Einträge würden weniger Platz in der DB verbrauchen und die Url würde kürzer werden.

    Steckt das auch dahinter oder was hat das auf sich?
    Und wie funktioniert das?
    Gut geraten ist halb gewußt.

  • #2
    Sie übergeben immer mehr Alpabetische Zeichen anstelle von reinen IDs. Warum?
    Das hat meistens einen ganz einfachen Grund: es ist nicht gewünscht, dass man alle vorhandenen Einträge fortlaufend abfragen kann.
    Wandeln die das wieder um, bevor die den Eintrag aus der DB ermitteln oder heißen auch so die Einträge in den Tabellen?
    Je nach dem. Teilweise werden die Zeichenketten über einen symmetrischen Algorithmus wieder in numerische Ids umgewandelt. Das hat allerdings den Nachteil, dass dahinter ein (knackbares) System steckt. Wenn man das verhindern will generiert man beim anlegen einen einzigartiken Token der sich zum Beispiel aus Zeit, Id und weiteren Parametern zusammensetzt. Den speichert man dann zusätzlich in der Datenbank.
    Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

    Kommentar


    • #3
      Original geschrieben von tontechniker
      Das hat meistens einen ganz einfachen Grund: es ist nicht gewünscht, dass man alle vorhandenen Einträge fortlaufend abfragen kann.
      Aha, ja daran hab ich noch garnicht gedacht. So wie ich das sehe hat das bis jetzt 3 gute Vorteile und 1 Nachteil. Der Nachteil wäre nur der Aufwand um das immer umzuwandeln.

      Und schade, ich hätte das schön gefunden, hätten die das auch so in der DB gespeichert.

      Hat diese Technik auch ein Namen? Sodas ich mal gezielter danach googlen kann.
      Gut geraten ist halb gewußt.

      Kommentar


      • #4
        Der Nachteil wäre nur der Aufwand um das immer umzuwandeln.
        Code:
        SELECT * FROM entries WHERE token = 'p34KM3z47'
        ?
        Und schade, ich hätte das schön gefunden, hätten die das auch so in der DB gespeichert.
        Wenn man das verhindern will generiert man beim anlegen einen einzigartiken Token der sich zum Beispiel aus Zeit, Id und weiteren Parametern zusammensetzt. Den speichert man dann zusätzlich in der Datenbank.
        Die Regeln | rtfm | register_globals | strings | SQL-Injections | [COLOR=silver][[/COLOR][COLOR=royalblue]–[/COLOR][COLOR=silver]][/COLOR]

        Kommentar


        • #5
          Also ich würde in der DB die normale Zahl speichern und für die URL dann mit base_convert oder base64_encode bzw. base64_decode arbeiten.
          hopka.net!

          Kommentar


          • #6
            Ich fand es ja gerade so schön, das man ein kurzen Parameter hat und keinen der 32 Zeichen lang ist. Was sich ja in der Suchmaschinenoptimierung bemerkbar macht.

            Je kürzer die Url und je relevanter die Url ist, desso besser. Deswegen mag ich es nicht, wenn ich da so viel drinne zu stehen habe.

            Code:
            SELECT * FROM entries WHERE token = 'p34KM3z47'
            Denn kann man das Feld token aber nicht als auto_increment nehmen.
            Aber man könnte das als Index mit anderen Tabellen verknüpfen,richtig?

            Und naja, ich persönlich empfinde das Ergebnis von base64_encode als zu lang. Wenn, denn würde ich mir selber eine kleine Funktion schreiben, die mir systematisch solche Strings bastelt. Von 0 an aufsteigent bis x,y,z und dann in den 2 stelligen Bereich von vorne.
            Gut geraten ist halb gewußt.

            Kommentar


            • #7
              Original geschrieben von Hopka
              Also ich würde in der DB die normale Zahl speichern und für die URL dann mit base_convert oder base64_encode bzw. base64_decode arbeiten.
              Den Ansatz finde ich relativ dümmlich (Den Ansatz, nicht dich, Hopka (vorsorglich mal feststell)), da man schnell dahinterkommen kann. Mein aktuelles Projekt basiert auf 32Zeichen langen md5()-Hashwerten, die sich aus der mysql_insert_id, dem aktuellen time()-Stamp und einem rand()-Wert zusammensetzt. Ob ich nun 6 Zeichen hab, oder 32, ist in meinem Projekt egal, und ist m.E. nicht so schnell durchforstbar, wie mal eben per Standart-PHP-Funktion was zu codieren.
              Liebe Grüße,
              SteKoe!

              PHP Tutorials
              Peter Kropff | Quakenet | Schattenbaum.net

              Kommentar


              • #8
                Original geschrieben von stekoe2000
                Den Ansatz finde ich relativ dümmlich (Den Ansatz, nicht dich, Hopka (vorsorglich mal feststell)), da man schnell dahinterkommen kann.
                Naja, der Ansatz bezieht sich auch nur darauf, wie man die Zeichenketten für die URLs erhalten kann. Wenn man etwas verschleiern will, dann muss man so oder so zufällige Werte mit einbeziehen. Und man kann natürlich auch zufällige Zahlen mit den base*-Funktionen umwandeln. Dann hilft es auch keinem, wenn er dahinter gekommen ist.
                hopka.net!

                Kommentar

                Lädt...
                X