@UffTaTaAlso bei mir funktioniert der Link ohne Probleme:
http://flv5.archiv.to/Getta/45ab86403939c034cbbf620a0577242f/4d91207e/00060000/0ad1a77c471c67cd53bb263f5c7ef8b6.mp4Kann sein, dass die URL neu generiert wird. Das könnte so funktionieren:
1. Beim Aufruf der Seite sendet dein Browser die unter dem Scope verfügbare Cookies an den Server
2. Server prüft, ob du ein Cookie mit der Sitzungsid hast
3. Wenn du keine hast, wird eine neue erzeugt und als Antwort an den Browser set-cookie Anweisung mit der neuen ID im Header übergeben.
Die Videos werden entweder ausserhalb des document_root der für die domain o. auch IP festgelegt wurde abgelegt oder durch Zugriffsschutz via HTTP unzugänglich gemacht. In der Datenbank könnten die folgenden Informationen vorliegen (nur wichtiges hier bedacht):
table "t_videos"
cols:
id | abs_pathrow:
FILE4A247AB1558D5 | /pfad/zum/video/auf/dem/server/rechner/torchwood.extdie URL "
http://archiv.to/GET/FILE4A247AB1558D5 (Archiv-Version vom 25.11.2010)" wird höhstwarscheinlich serverseitig mithilfe von mod_rewrite umgeschrieben und der pfad-segment nach GET wird dann vom script, auf den die anfrage umgeleitet wird dazu verwendet, aus der datenbank anhand der ID den tatsächlichen Pfad der Datei auf dem Server zu ermitteln. Sie ist zwar über HTTP direkt nicht erreichbar, aber der Script arbeitet local auf dem System und ist davon nicht betrofen.
Nun wird eine 2. Tabelle verwendet:
table "t_video_links"
cols:
link_hash | f_file_id | f_session_idrows:
2e99c555cb9f37ba27b2b1221325c3ff | FILE4A247AB1558D5 | deine_session_id, falls datenbankgestützwenn du nun eine Anfrage an "http://FLV5.archiv.to/Getta(http://FLV5.archiv.to/Getta)" sendest, werden die path-segments der URI, wieder mithilfe einer umleitung mit mod_rewrite dann eigenhändig vom script ausgewertet und entsprechende datenbankabfragen getätigt um rauszufinden, welche file_id dahinter steckt (aus tabelle "t_video_links") und dann den pfad auf dem system zu ermitteln (aus tabelle "t_videos"). Wenn man noch die Session mit der des nutzers vergleicht kann man dafür sorgen, dass ein video-link nnur dann gefunden wird, wenn sowohl link_hash stimmt als auch die f_session_id richtig ist. ansonsten wird eine meldung erzeugt, dass das video/datei nicht gefunden wurde. das wäre die erklärung, warum das nicht bei anderen funktioniert.
zusätzlich könnte man noch ein unix_tstamp oder date, je nach db-system beim erstellen eines links speichern und anschließend bei aufruf prüfen ob eine bestimtme anzahl an sekunden vergangen ist und dann statt die video-daten byteweise auszulesen und als antwort zu senden den link aus der db löschen und eine fehlermeldung ausgeben oder auch einfach schweigen.
Das ist nur ein szenario, wie das laufen könnte... Es wird sicher vieles genau so sein. Aber für den Dateinamen wird noch der md5 wert der dateidaten verwendet. das kann entweder deko sein oder ein teil des systems.
