DE10349723A1

DE10349723A1 - Verfahren zur Überprüfung der Berechtigung einer Anfrage eines Nutzers auf Bereitstellung eines Content durch einen Contentserver

Info

Publication number: DE10349723A1
Application number: DE10349723A
Authority: DE
Inventors: Frank Simon; Herwig Henseler
Original assignee: ECCE TERRAM INTERNET SERVICES; ECCE TERRAM INTERNET SERVICES GmbH
Current assignee: ECCE TERRAM INTERNET SERVICES; ECCE TERRAM INTERNET SERVICES GmbH
Priority date: 2003-10-23
Filing date: 2003-10-23
Publication date: 2005-06-09

Abstract

Offenbart ist ein Verfahren zur Überprüfung der Berechtigung einer Anfrage eines Nutzers (1) auf Bereitstellung eines Content durch einen Contentserver (2), wobei die Anfrage durch Übermittlung einer Zeichenfolge erfolgt, die ein den Nutzer (1) identifizierendes Token umfasst, und wobei der Content nur dann dem Nutzer (1) bereitgestellt wird, wenn das Token gültig ist. DOLLAR A Um eine unabhängig vom Protokoll persistente Authentifizierung zu ermöglichen, wird vorgeschlagen, dass die Anfrage an einen Proxyserver (3) gerichtet wird und das Token eine Subdomain auf dem Proxyserver (3) kennzeichnet.

Description

Die Erfindung betrifft ein Verfahren zur Überprüfung der Berechtigung einer Anfrage eines Nutzers auf Bereitstellung eines Content durch einen Contentserver, wobei die Anfrage durch Übermittlung einer Zeichenfolge erfolgt, die ein den Nutzer identifizierendes Token umfasst, und wobei der Content nur dann dem Nutzer bereit gestellt wird, wenn das Token gültig ist.

Die Bezahlung von Web-Content stellt ein Standardproblem im Internet dar. Allgemein bekannte Lösungen konzentrieren sich dabei auf bestimmte Bezahlformen (z. B. Pay-per-Item) oder Inhalte (z. B. HTML-Seiten oder PDF). Beispielsweise wird im Rahmen eines bekannten Verfahrens der Zugriff auf einen Multimedia-Content über ein Payment-Portal geleitet.

Der Nutzer authentifiziert sich gegenüber einem Webserver bzw. Skript über ein Standardverfahren, welches den Nutzer trotz nichtpersistenter Verbindung später wieder authentifiziert. Hierbei muss der Browser des Nutzers dem Webserver bei einem Zugriff eine eindeutige Kennung liefern. Die bekannten Verfahren „Basic Authentification System" (BAS, RFC 2617) oder Cookies finden hier Verwendung. Authentifizierung via BAS und Cookies werden von allen heute gängigen Browsern unterstützt.

Der Browser übernimmt im Rahmen der bekannten Verfahren eine „aktive" Rolle im Authentifizierungsprozess, indem er bei einem Zugriff die Authentifizierungsdaten des Nutzers präventiv mitliefert. Hierzu wird eine individuelle Zeichenfolge – ein sogenanntes Token – generiert, die den Nutzer identifiziert. Die Authentifizierung des Nutzers erfolgt über ein Skript oder über entsprechende Methoden direkt im Webserver.

Seitens des Servers wird dann lediglich noch abgefragt, ob diese mitgelieferten Daten korrekt sind und der Zugriff mit den gewünschten Inhalten erfüllt oder ein entsprechender Fehlercode zurückgeliefert. Mittels des Fehlercodes wird gegebenen Falls der Benutzer aufgefordert, sich zu authentifizieren und informiert, wie er sich die hierfür erforderlichen Daten beschaffen kann.

Im Rahmen der bekannten Verfahren wird das Token als GET oder POST-Parameter übergeben. Die Authentifizierungsinformation geht beim Surfvorgang, insbesondere beim Verlassen der aktuellen Site verloren. Die bekannten Verfahren sind aus diesem Grund unter zwei Gesichtspunkten problematisch: Zum Einen ist systembedingt der Zugriff auf Content auf diese Weise nur über HTTP möglich. Beim Zugriff auf Multimediainhalte über andere Protokolle (beispielsweise über rsp) ist eine Authentifizierung mit den bekannten Verfahren nicht möglich.

Zum Andern erfordert der Zugriff auf Content, der sich auf einem anderen Server mit anderem Hostnamen und anderer IP-Adresse oder lediglich in einem anderen Verzeichnis befindet, eine erneute Authentifizierung. Der Browser kann in diesen Fällen bei Verwendung der bekannten Verfahren die Authentifizierungsdaten über GET- oder POST nicht präventiv mitliefern. Der Nutzer muss die Authentifizierungsdaten erneut eingeben, damit der Browser diese mit den neuen Serverdaten verbinden kann.

Aufgabe der Erfindung

Der Erfindung liegt die Aufgabe zugrunde, eine unabhängig vom Protokoll persistente Authentifizierung zu ermöglichen. Gesucht wird insbesondere ein Verfahren zur Realisierung von Payment-Lösungen, das keine Vorbedingung für den technischen Betrieb des zu bezahlenden Content darstellt und in dem jegliche Art von Content vergebührt werden kann.

Lösung

Ausgehend von den bekannten Verfahren wird erfindungsgemäß vorgeschlagen, dass die Anfrage an einen Proxyserver gerichtet wird und das Token eine Subdomain auf dem Proxyserver kennzeichnet. Die Verwendung eines Proxyservers ist grundsätzlich bekannt. Sie erlaubt die Kontaktierung und die Spezifikation der Kontaktierung von Subdomains.

Die erfindungsgemäße Interpretation eines individuell für einen authentifizierten Benutzer dynamisch generierten Token als Namen einer Subdomain ist vom verwendeten Protokoll unabhängig und stellt in dieser Hinsicht – im Gegensatz zu den bekannten Verfahren – keine Vorbedingung für den technischen Betrieb oder die Art des Content. Der Proxyserver wird hierbei derart konfiguriert, dass Subdomainnamen mit Token, die mittels des jeweils eingesetzten Verfahrens generiert werden, zunächst als möglicher Weise gültige Subdomain angesehen werden.

Erfolgt eine Anfrage an eine solche Subdomain, so überprüft der Proxyserver mittels eines geeigneten Algorithmus, ob die Authentifizierung gültig ist und bearbeitet bejahenden Falls die Anfrage. Wird die Gültigkeit der Authentifizierung verneint, so wird statt dessen eine Fehlerbehandlung eingeleitet – beispielsweise eine Fehlermeldung für den Nutzer ausgegeben.

Im Rahmen eines erfindungsgemäßen Verfahren wird vorzugsweise das Token von einem Tokenserver generiert, sofern sich der Nutzer auf diesem zuvor authentifiziert hat. Die Verwendung eines Tokenservers ermöglicht eine Automatisierung der Tokengenerierung abhängig von einer Authentifizierung des Nutzers.

Zur Authentifizierung können hierbei die allgemein bekannten Verfahren – beispielsweise die manuelle Eingabe von Nutzername und Passwort, bei höheren Sicherheitsanforderungen ein Verfahren mit nur einmalig verwendbarer Transaktionsnummer (TAN), mit individueller Chipkarte (HBCI-Verfahren o. ä.) oder unter Verwendung sonstiger, beispielsweise biometrischer Daten des Nutzers – zum Einsatz kommen.

Alternativ können im Rahmen eines erfindungsgemäßen Verfahrens auch vorgegebene Token manuell zur Kennzeichnung einer Subdomain verwendet werden. Beispielsweise kann ein Token aus einer Kombination aus einem individuellen Zugangscode (wie Nutzername oder PIN) und einer TAN als Subdomainname manuell eingegeben werden.

Bei Verwendung eines Tokenservers im Rahmen eines erfindungsgemäßen Verfahrens erfolgt die Anfrage des Nutzers vorzugsweise durch eine Redirect-URL auf den Proxyserver. So kann im Anschluss an die Authentifizierung des Nutzers auf dem Tokenserver die Anfrage des Nutzers automatisiert ausgeführt werden.

Bei Verwendung eines Tokenservers im Rahmen eines erfindungsgemäßen Verfahrens speichert bevorzugt der Tokenserver das Token in einer Tokendatenbank, die der Proxyserver zur Überprüfung der Gültigkeit des Token abfragt, wobei das Token dann gültig ist, wenn es in der Tokendatenbank gespeichert ist.

Die Abfrage einer Tokendatenbank bietet eine technisch einfache Möglichkeit, die Gültigkeit eines von einem Nutzer im Rahmen einer Anfrage verwendeten Token zu überprüfen. Darüber hinaus können alle zur Verwaltung der Nutzer und der Ihnen zugeordneten Token benötigten Informationen ausschließlich auf dem Tokenserver gehalten werden.

Alternativ kann der Proxyserver derart konfiguriert sein, dass er einen zu dem im Tokenserver zur Generierung des Token verwendeten Verfahren inversen Algorithmus zum Validieren des Token anwendet und das im Erfolgsfall das verwendete Token als gültig angesehen wird. Das Token wird hierbei vorzugsweise kryptographisch verschlüsselt, so dass die in ihm enthaltenen Informationen wie Nutzer, Lebensdauer, Prüfsumme nicht durch einfaches Ausprobieren ermittelt werden können. Auf diese Weise kann auf eine zentrale Tokendatenbank verzichtet werden.

Im Rahmen eines erfindungsgemäßen Verfahrens umfasst vorzugsweise die im Rahmen der Anfrage des Nutzers übermittelte Zeichenfolge eine relative Adresse des Content auf dem Contentserver. Bei der Verfolgung relativer Links auf dem Proxyserver bleibt der Subdomainname unabhängig von dem verwendeten Protokoll erhalten.

So können mehrere Contents in Folge – auch unter Verwendung unterschiedlicher Protokolle – ohne erneute Authentifizierung des Nutzers abgerufen werden. Es besteht sogar die Möglichkeit, mittels Redirect-URLs auf Content auf räumlich getrennten Servern mit nur einer einmaligen Authentifizierung komfortabel zuzugreifen, wenn diese über einen vergleichbaren Proxy-Algorithmus verfügen.

Bei Verwendung eines Tokenservers im Rahmen eines erfindungsgemäßen Verfahrens generiert bevorzugt der Tokenserver das Token auf eine Anfrage des Proxyservers. Durch die Kausalverknüpfung der auf Proxyserver und Tokenserver ausgeführten Verfahrensschritte kann das erfindungsgemäße Verfahren automatisiert und die Handhabung durch den Nutzer erheblich erleichtert werden.

Im Rahmen eines derartigen erfindungsgemäßen Verfahrens erfolgt vorzugsweise die Anfrage des Proxyservers durch eine Redirect-URL auf den Tokenserver. Innerhalb der Redirect-URL werden hierbei bevorzugt die Daten des zunächst abgelehnten Zugriffs, insbesondere der Ort des gewünschten Content und das verwendete Protokoll beispielsweise über POST-Parameter an den Tokenserver übergeben.

So kann der Tokenserver wiederum eine Redirect-URL auf den Proxyserver generieren, so dass der zuvor abgelehnte Zugriff ohne erneute Eingabe des Nutzers automatisiert ausgeführt werden kann. Generiert im Rahmen eines erfindungsgemäßen Verfahrens der Tokenserver das Token auf eine Anfrage des Proxyservers, so umfasst die im Rahmen der Anfrage des Proxyservers übermittelte Zeichenfolge eine relative Adresse des Content auf dem Contentserver.

Weiterhin wird im Rahmen eines derartigen erfindungsgemäßen Verfahrens vorteilhafter Weise eine Anfrage des Proxyservers an den Tokenserver generiert, wenn die Zeichenfolge der Anfrage des Nutzers kein gültiges Token umfasst. Der Proxyserver kann auch derart konfiguriert sein, dass jeder Zugriff auf einen Content ohne Angabe einer Subdomain oder auf eine Subdomain, die kein möglicher Weise mittels des jeweils eingesetzten Verfahrens generiertes Token enthält, an den Tokenserver verwiesen wird.

In einem erfindungsgemäßen Verfahren kann insbesondere der Tokenserver ein Paymentserver sein. Das erfindungsgemäße Verfahren erlaubt dann auf eine für Provider und Nutzer gleichmaßen komfortable und sichere Weise die Bereitstellung und Nutzungsabrechnung von kostenpflichtigem Content unabhängig von der Art des Content und von dem verwendeten Protokoll. Hierbei ist die Art des Payment-Portals nicht eingeschränkt.

In einem erfindungsgemäßen Verfahren wird vorzugsweise der Content nur dann dem Nutzer bereit gestellt, wenn zusätzlich die IP des Nutzers bei der Anfrage auf Bereitstellung des Content mit der IP bei der Authentifizierung auf dem Tokenserver übereinstimmt. Darüber hinaus ist es von Vorteil, wenn die Gültigkeit des Token nach einer vorgegebenen Zeit verfällt. Durch beide Maßnahmen für sich, insbesondere aber durch ihre Kombination wird die Sicherheit des erfindungsgemäßen Verfahrens gegen unauthorisierten Zugriff auf den Content deutlich erhöht. Hiermit wir das Missbrauchsrisiko durch beabsichtigte oder unbeabsichtigte Weitergabe oder Veröffentlichung eines Token minimiert.

Auf ähnliche Weise, nämlich durch Verwendung eines authentifizierenden Token kann prinzipiell auch jeder Remote-Zugriff mit einem beliebigen Protokoll wie telnet oder ftp und sogar jeder beliebige Objekt-, Datei- oder Programmzugriff von einer Authentifizierung abhängig gemacht werden. Beispielsweise kann durch Verwendung einer Firewall und Vorschaltung der beschriebenen Authentifizierung und Tokengenerierung eine Zugriffskontrolle auf Anwendungen wie die Datenbank Filemaker realisiert werden, die kein eigenes Rechtesystem bereitstellen.

Das Token kann hierbei die Funktion eines temporären nutzerspezifischen Rootverzeichnisses erfüllen, auf das ausschließlich die für den Zugriff erforderlichen Programm- und Datenverzeichnisse dynamisch gemappt werden.

Ausführungsbeispiel
Die Erfindung wird nachfolgend anhand eines Ausführungsbeispiels erläutert. Die Zeichnungsfigur zeigt eine schematische Darstellung der wichtigsten zwischen Nutzer 1, Contentserver 2, Proxyserver 3 und Tokenserver 4 zum Abrufen eines im Schema nicht dargestellten Content ausgetauschten Informationen.
Der Content wird von einem gleichfalls im Schema nicht dargestellten Provider über ein Webportal angeboten. Der Tokenserver 4 ist in bekannter Weise als "Apache 1.3.26 HTTP Server", der Proxyserver 3 als "Apache 1.3.26 Proxy Server" implementiert. Der Contentserver 2 ist ein allgemein bekannter Inhalteserver.
Contentserver 2, Proxyserver 3 und Tokenserver 4 sind im Beispiel als Dienste auf demselben Rechner implementiert, können aber auch auf unterschiedlichen, räumlich getrennter Hardware implementiert sein. Die Domain des Providers trägt hier beispielsweise den Namen "provider.de", das Webportal wird unter "www.provider.de" angesprochen. Der Contentserver 2 trägt den Namen "content.provider.de und der geschützte Content ist ein HTML-Dokument mit der relativen Adresse "/geschuetzt.html" auf dem Contentserver 2.
Der Content des Contentservers 2 liefert keine absoluten URLs mit Hostnamen, die direkt auf den Contentserver 2 zeigen würden. Alle Links sind entweder relativ oder enthalten zumindest keinen Hostnamen. Der Nutzer 1 führt zunächst mittels seines Browsers einen nicht dargestellten ersten Zugriff auf den Proxyserver 3 aus, der alle Adressen der Domain "provider.de" verwaltet.
Der geschützte Content befindet sich in dem in allgemein bekannter Weise mittels BAS geschützen Bereich "www.provider.de/cgi-bin/member" und wird vom Nutzer 1 über den Link "http://www.provider.de/cgibin/member/p4z.pl?ER_Do=createToken&Abo_RedirectTo=content.provider.de/geschuetzt.h tml" angefordert.
Das aufgerufene FastCGI-Perlskript "p4z.pl" ist Teil der Implementation des Tokenservers 4 und überprüft zunächst in allgemein bekannter Weise die Identität des Nutzers 1. Dieser gibt hierzu in einer Eingabe 5 seinen Login "nutzer" und sein gültiges Passwort "geheim" ein. Diese Eingabe 5 kann durch den Browser des Nutzers 1 automatisiert erfolgen.
Das Authentifizierungsmodul ist sowohl auf dem Tokenserver 4 als auch auf dem Proxyserver 3 in bekannter Weise über das Apache-Modul "mod_auth_pgsql_et" implementiert und übergibt als relevante Parameter den Login und das Passwort des Nutzers 1, die URL, auf die der Nutzer 1 zugreifen möchte, den Hostnamen, unter dem der Proxyserver 3 angesprochen wurde sowie die IP-Nummern des Clients und des Servers an eine plpgsql-Prozedur.
Der Tokenserver 4 stellt anhand einer nicht dargestellten Nutzerdatenbank die Gültigkeit des Login und des Passworts fest, generiert anschließend aus Zufallsziffern, einer Codierung des aktuellen Datums sowie der Prozessnummer des Skriptes das Token "11234993326193888653" und übermittelt dieses in einem verschlüsselten Schreibvorgang 6 an eine Tokendatenbank 7, die gleichfalls Teil der Implementation des Tokenservers 4 ist. Die Tokendatenbank 7 ist in bekannter Weise in "PostgreSQL" implementiert und enthält neben den notwendigen Tabellen für payment und Authentifizierung die Tabelle mit den Token, nämlich das Token selber, den Login des Nutzers 1, die IP-Nummer des Zugriffs und das Verfallsdatum.
Zuletzt gibt das Skript als Antwort 8 den 302-Redirect "http://11234993326193888653.content.provider.de/geschuetzt.html" an den Browser des Nutzers 1 zurück. Der Hostname mit dem Token hat unmittelbar kein Äquivalent in der Hard ware des Servers. Vielmehr ist der Nameserver derart konfiguriert, dass alle Hosts unter der Domain des Providers die IP des Proxyserver 3 erhalten.
Ohne erneute Interaktion mit dem Nutzer 1 führt der Browser des Nutzers 1 den Zugriff 9 auf die angegebene URL auf dem Proxyserver 3 zu. Der Proxyserver 3 ist derart implementiert, dass er den Domainnamen unterhalb des Namens des Contentservers 2 als Token interpretiert und stellt im Rahmen einer Datenbankabfrage 10 an die Tokendatenbank 7 einschließlich eines Vergleichs des dort gespeicherten Verfallsdatums mit seiner Systemzeit dessen Gültigkeit und durch einen Vergleich der dort gespeicherten IP des Nutzers 1 mit der IP des aktuellen Zugriffs die Identität des Nutzers 1 fest.
Der Proxyserver 3 verwendet das oben bereits beschriebene Authentifizierungsmodul, ruft jedoch eine andere plpgsql-Prozedur auf und gleicht den Hostnamen beim Zugriff mit der in der Datenbank vorhandenen Tokentabelle ab. Sodann generiert der Proxyserver 3 eine Anforderung 11 an den Contentserver 2, erhält von diesem den geschützten Content und liefert letzteren in einer abschließenden Antwort 12 an den Browser des Nutzers 1 aus.
Hätte der Proxyserver 3 keinen Domainnamen unterhalb des Namens des Contentservers 2 oder nicht die Gültigkeit des Tokens oder nicht die Identität des Nutzers 1 erkannt, so würde er statt dessen wiederum in einer alternativen Antwort 13 einen 302-Redirect auf den Tokenserver 4 an den Browser des Nutzers 1 zurück geben, das Skript des Tokenservers 4 würde in einer erneuten Anfrage 14 Login und Passwort des Nutzers 1 abfragen, ein neues Token generieren, in der Tokendatenbank 7 speichern und in einem neuen 302-Redirect zurück geben.
Der an den Browser des Nutzers 1 weitergeleitete Content enthält in relativen Adressen Verweise auf Grafiken und Filme. Diese fordert der Browser des Nutzers 1 in nicht dargestellter Weise mit verschiedenen Protokollen mit direktem Zugriff auf den Proxyserver 3 an. Der Hostname mit dem Token bleibt dabei erhalten.
Das als gültig akzeptierte Token wird kurzzeitig als gültig im Proxyserver 3 zwischengespeichert. So wird die Performance des Systems verbessert, da der Zugriff auf die verknüpften Contents (vorübergehend) keine neuen Zugriff auf die Tokendatenbank 7 erfordert. Ein Zugriff eines Nutzers 1 auf einen komplexen Content kann innerhalb kürzester Zeit zu einer Vielzahl von Zugriffen auf den Proxy-Server führen.
Im Falle eines verfallenen Tokens könnte dies zu einer Race Condition mit sehr vielen neuen Authentifizierungen und entsprechender Serverlast führen. Um dies zu Vermeiden werden daher neu generierte Tokens nicht nur in der Tokendatenbank 7, sondern auch unmittelbar auf dem Tokenserver 4 kurzzeitig zwischengespeichert, um gegebenen Falls neue Redirects direkt zurückgeben zu können.
Nach dem Verfallsdatum des Token greift der Nutzer 1 (beispielsweise durch Reload im Browser) in nicht dargestellter Weise erneut auf den geschützten Content zu. Dieser Zugriff wird vom Proxyserver 3 abgelehnt, da das Token verfallen ist. Stattdessen wird wiederum der bereits bekannte 302-Redirect vom Proxyserver 3 http://www.provider.de/cgibin/member/p4z.pl?ER_Do=createToken&Abo_RedirectTo=cont ent.provider.de/geschuetzt.html" generiert.
Der Browser liefert Login und Passwort für den (jetzt bekannten) BAS-Bereich gleich mit, so dass der Nutzer 1 ohne eigenes Zutun authentifiziert wird. Mit dem nun generierten Token erfolgt der Zugriff auf den geschützten Content wie oben beschrieben.
In derselben Weise kann auch ein Zugriff auf einen Multimedia-Datenstream erfolgen, der von einem anderen, im Schema nicht dargestellten Contentserver 2, von dem Realserver "realserver.provider.de" bereit gestellt wird. Der Realserver muss ist derart konfiguriert, dass Zugriffe nur über den Proxyserver 3 erfolgen dürfen. Der erste Zugriff des Nutzers 1 erfolgt dann beispielsweise in der Form "http://www.provider.de/cgibin/member/p4z.pl?ER_Do=createToken&Abo_RedirectTo=real server.provider.de/media/geschuetzt.rm".
Mit einem neu generierten Token "91135194773177243621013" lautet der an den Browser des Nutzers 1 zurück gegebene 302-Redirect dann "http://91135194773177243621013.realserver.provider.de/media/geschuetzt.rm". Im Unterschied zu dem zuvor beschriebenen Beispiel liefert der Realserver kein Dokument, sondern einen kontinuierlichen Datenstrom an den Browser des Nutzers 1, beziehungsweise an das in diesem ausgeführte Plugin. Wie zuvor erfolgt die Authentifizierung des Nutzers 1 vollständig in der Tokenserver-Proxyserverkombination.

1: Nutzer
2: Contentserver
3: Proxyserver
4: Tokenserver
5: Eingabe
6: Schreibvorgang
7: Tokendatenbank
8: Antwort
9: Zugriff
10: Datenbankabfrage
11: Anforderung
12: Antwort
13: Antwort
14: Anfrage

Claims

Verfahren zur Überprüfung der Berechtigung einer Anfrage eines Nutzers (1) auf Bereitstellung eines Content durch einen Contentserver (2), wobei die Anfrage durch Übermittlung einer Zeichenfolge erfolgt, die ein den Nutzer (1) identifizierendes Token umfasst, und wobei der Content nur dann dem Nutzer (1) bereit gestellt wird, wenn das Token gültig ist, dadurch gekennzeichnet, dass die Anfrage an einen Proxyserver (3) gerichtet wird und das Token eine Subdomain auf dem Proxyserver (3) kennzeichnet.
Verfahren nach dem vorgenannten Anspruch, dadurch gekennzeichnet, dass das Token von einem Tokenserver (4) generiert wird, sofern sich der Nutzer (1) auf diesem zuvor authentifiziert hat.
Verfahren nach dem vorgenannten Anspruch, dadurch gekennzeichnet, dass die Anfrage des Nutzers (1) durch eine Redirect-URL auf den Proxyserver (3) erfolgt.
Verfahren nach einem der Ansprüche 2 bis 3, dadurch gekennzeichnet, dass der Tokenserver (4) das Token in einer Tokendatenbank (7) speichert, die der Proxyserver (3) zur Überprüfung der Gültigkeit des Token abfragt, wobei das Token dann gültig ist, wenn es in der Tokendatenbank (7) gespeichert ist.
Verfahren nach einem der vorgenannten Ansprüche, dadurch gekennzeichnet, dass die im Rahmen der Anfrage des Nutzers (1) übermittelte Zeichenfolge eine relative Adresse des Content auf dem Contentserver (2) umfasst.
Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass der Tokenserver (4) das Token auf eine Anfrage des Proxyservers (3) generiert.
Verfahren nach dem vorgenannten Anspruch, dadurch gekennzeichnet, dass die Anfrage des Proxyservers (3) durch eine Redirect-URL auf den Tokenserver (4) erfolgt.
Verfahren nach einem der Ansprüche 6 bis 7, dadurch gekennzeichnet, dass die im Rahmen der Anfrage des Proxyservers (3) übermittelte Zeichenfolge eine relative Adresse des Content auf dem Contentserver (2) umfasst.
Verfahren nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass eine Anfrage des Proxyservers (3) an den Tokenserver (4) generiert wird, wenn die Zeichenfolge der Anfrage des Nutzers (1) kein gültiges Token umfasst.
Verfahren nach einem der Ansprüche 2 bis 9, dadurch gekennzeichnet, dass der Tokenserver (4) ein Paymentserver ist.
Verfahren nach einem der Ansprüche 2 bis 10, dadurch gekennzeichnet, dass der Content nur dann dem Nutzer (1) bereit gestellt wird, wenn zusätzlich die IP des Nutzers (1) bei der Anfrage auf Bereitstellung des Content mit der IP bei der Authentifizierung auf dem Tokenserver (4) übereinstimmt.
Verfahren nach einem der vorgenannten Ansprüche, dadurch gekennzeichnet, dass die Gültigkeit des Token nach einer vorgegebenen Zeit verfällt.