Domumente schützen

[Martin Hein]

Hallo Forum,

folgende Problematik:

Auf meiner PHP/Mysql-Anwendung gibt es einen geschlossenen Bereich.
Ergo: Forumlar mit usr und passwd. In diesem geschlossen Bereich
gibt es PDF-Downloads (,die natürlich auch möglichst geschützt sein
sollten). Meine erste Idee war, das Verzeichnis, in dem diese
Dokumente liegen per .htaccess/.htuser zu schützen und nach dem
der User sich eingelogget hat, diese Login-Daten zu verwenden, um
die Links auf die Dokumente aus dem geschützeten Bereich entsprechend
zu maskieren:

http://username:[e-mail]/directory/

... was bei meinem ersten Test auch funktioniert hat. Nun bin ich
aber darauf gestossen, dass das laut rfc "NOT ALLOWED" ist und im
IE7 garnicht funktioniert.

Was sagt ihr dazu ? Gibts Alternativen ?

beste gruesse,
martin

[Der Martin]

Hi lieber Namensvetter,

Meine erste Idee war, das Verzeichnis, in dem diese Dokumente liegen per .htaccess/.htuser zu schützen und nach dem der User sich eingelogget hat, diese Login-Daten zu verwenden, um die Links auf die Dokumente aus dem geschützeten Bereich entsprechend zu maskieren:

http://username:[e-mail]/directory/

das ist eine nette Idee, aber wie du schon feststellst, bewegst du dich damit außerhalb jeglicher Standards. Tatsächlich braucht der IE6 erst einen Tritt in den Hintern, um solche URL-Notationen zu akzeptieren; ob das beim IE7 immer noch geht, weiß ich nicht.

Was sagt ihr dazu ? Gibts Alternativen ?

Warum legst du nicht einfach die PDFs im gleichen Verzeichnis ab wie das Dokument, das sowieso aufgerufen wird und den HTTP-AUTH-Dialog anstößt? Denn wenn sich der Browser einmal erfolgreich beim Server authentifiziert hat, schickt er diese Zugangsdaten bei nachfolgenden Zugriffen auf das gleiche Verzeichnis automatisch wieder mit.

Schönen Abend noch,
 Martin

PS: Du plenkst.

[Martin Hein]

Hello,

das ist eine nette Idee, aber wie du schon feststellst, bewegst du dich damit außerhalb jeglicher Standards. Tatsächlich braucht der IE6 erst einen Tritt in den Hintern, um solche URL-Notationen zu akzeptieren; ob das beim IE7 immer noch geht, weiß ich nicht.

Auf meinem IE6 funktioniert's. Allerdings ist das eine Version,
die unter multipleIEs läuft und bei der scheinbar das entsprechende
Sicherheitsupdate fehlt. Der IE7 macht das definitiv nicht. Was
mich wundert ist, dass Mozilla das problemlos macht.

Warum legst du nicht einfach die PDFs im gleichen Verzeichnis ab wie das Dokument, das sowieso aufgerufen wird und den HTTP-AUTH-Dialog anstößt? Denn wenn sich der Browser einmal erfolgreich beim Server authentifiziert hat, schickt er diese Zugangsdaten bei nachfolgenden Zugriffen auf das gleiche Verzeichnis automatisch wieder mit.

Das geht so einfach nicht, weil es keine einzelnen Seiten, die
in verschiedenen Verzeichnissen liegen gibt, sondern lediglich
eine index.php, die aus dynamisch zusammengesetzen Contents
besteht. Das liesse sich aber sicher lösen, indem ich ein Pixel
auf deser Seite einbaue, dass in dem geschützten Verzeichnis
liegt.

Daraus folgt aber, dass der User sich zweifach einloggen muss.
Nämlich:

a) im Form (die Logindaten werden benötigt, um damit entsprechende
   DB-Inhalte zu holen: "Sehr geehrte Frau Musterfrau").

b) in der access-Box des Browsers für die Dokumente.

... und genau das wollte ich ja mit dem Link umgehen.

Ich frage mich, wie das bei meiner "Strato-Rechnung online" geht.
Wahrscheinlich werden die PDFs erst beim Aufruf erstellt.

beste gruesse,
martin

[Martin Hein]

Ich frage mich, wie das bei meiner "Strato-Rechnung online" geht.
Wahrscheinlich werden die PDFs erst beim Aufruf erstellt.

Und da scheine ich mich getäuscht zu haben! Interessantes Verhalten
Meine "Rechnung online" liegt unter:

https://dms.strfit.de/18550721/DRP30111375.pdf

nachdem ich mich bei Strato eingelogged habe

UND

nachdem ich mich dort wieder ausgelogged habe

UND

der Link ist der selbe, wenn ich mich mit zwei
unterscheidlichen Browsern einlogge.

ABER

wenn ich den dritten Browser starte, den Link aufrufe,
ohne mich einzuloggen, funktioniert er dort nicht. Ich
werde nach einer Fehlerseite umgeleitet.

Das finde ich einigermassen abgefahren und bin neugierig, wie
das geht!

beste gruesse,
martin

[Martin Hein]

Hallo Forum,

wie schön, wenn sich manche Probleme im Dialog mit sich selbst
zu klären scheinen ;)

Ich bin einen grossen Schritt weiter:

Ich leite alle Anfragen auf das zu schützende Verzeichnis per
mod-rewrite auf ein PHP-Script um, dass die erstmal die Authentifizierung (SESSION) checkt und daraufhin entweder:

a) umleitet oder
b) das angeforderte PDF ausgibt

Mit b) bin ich mir nicht sicher:

header("Content-type: application/pdf");
header("Content-Disposition: inline; filename="test.pdf"");
readfile($file);

... macht, was ich will. Allerdings:

1. versteht das jeder (gängige IE>=6, Mozilla, Opera>=8, Safari)
      Browser?
2. Wie geht das mit .doc, .xls, .ppt ? Aus die Dateiendung
      den Content-type annehmen ?

beste gruesse,
martin

[Cheatah]

Hi,

1. versteht das jeder (gängige IE>=6, Mozilla, Opera>=8, Safari)
      Browser?

jeder HTTP-Client versteht HTTP. Was ein Server irgendwann mal gemacht haben mag, interessiert ihn nicht.

2. Wie geht das mit .doc, .xls, .ppt ? Aus die Dateiendung
      den Content-type annehmen ?

Wenn das der Weg ist, wie Du die Datei-Art erkennst, dann ja. Alternativ könntest Du alle Dateien, die älter als ein Jahr sind, als PDF-Ressource verschicken und bei allen anderen aus der Summe der ASCII-Werte des Dateinamens mit Hilfe einer nummerischen Tabelle den Typus ermitteln - falls das bei Dir Sinn ergibt. Jedes Verfahren, das Deinen Bedürfnissen entspricht, ist richtig.

Cheatah

[Martin Hein]

Hi,

Wenn das der Weg ist, wie Du die Datei-Art erkennst, dann ja. Alternativ könntest Du alle Dateien, die älter als ein Jahr sind, als PDF-Ressource verschicken und bei allen anderen aus der Summe der ASCII-Werte des Dateinamens mit Hilfe einer nummerischen Tabelle den Typus ermitteln - falls das bei Dir Sinn ergibt. Jedes Verfahren, das Deinen Bedürfnissen entspricht, ist richtig.

verstehe nicht wirklich, was Du mir sagen willst, aber aus der Dateiendeung den Mime-Type zu ermitteln, kommt mir komisch vor. Erscheint mir irgendwie unsauber. Was ich nicht verstehe, ist
warum man den Mime-Type bei upgeloadeten Files in ner Variable stehen hat und warum das so problematisch ist, wenn das File schon
auf dem Server vorhanden ist.

martin

[Cheatah]

Hi,

verstehe nicht wirklich, was Du mir sagen willst, aber aus der Dateiendeung den Mime-Type zu ermitteln, kommt mir komisch vor. Erscheint mir irgendwie unsauber.

Apache macht in seiner Default-Einstellung nichts anderes. Ob das in Deinem Fall hinhaut, kann aber nur einer sagen: Du.

Was ich nicht verstehe, ist warum man den Mime-Type bei upgeloadeten Files in ner Variable stehen hat

Weil der Client etwas entsprechendes versendet hat. Somit ist diese Information übrigens zu exakt 0% vertrauenswürdig.

und warum das so problematisch ist, wenn das File schon auf dem Server vorhanden ist.

Weil niemand etwas entsprechendes sagt. Die serverseitige Programmlogik spricht schließlich an der Stelle mit einem Dateisystem, und die meisten mir bekannten Dateisysteme haben keinen Schimmer von etwas, dass sich "MIME-Type" nennt.

Cheatah

[Martin Hein]

Hi,

ich glaube, ich habe grob verstanden:

MIME-TYPE ist die Information, wie ein Client mit einer Datei
umgehen soll. Beim Upload teilt der Client dem Server mit, wie
er mit der Datei umgehen würde. Deshalb ist diese Information
beim Upload vorhanden. Dem Webserver kann das eigentlich egal
sein. Wenn der Webserver eine Datei zum Client schickt, kann
er diese Information aus der Dateiendung rückschliessen und
mitschicken. Die Zuordnung kann aber auf dem Client eine ganz
andere sein. Z.B. Schickt der Webserver 'application/pdf' mit,
der Client kann mit dieser Zuordnnung nichts anfangen, weil der
MIME-TYPE ihm unbekannt ist (weil z.b. kein PDF-Reader installiert
ist) und er bietet die ihm unbekannte Datei zum Download an.

Mein Wrapper-Script funktioniert nun wie folgt:

1. per mod_rewrite wird eine Anfrage auf ein zu schützendes
   Dokument nach wrapper.php?angefordertes=dokument
   &umleitung=nach umgeleitet.

2. wrapper.php nimmt eine Überprüfung vor und

a) gibt entweder $angefordertes=dokument (z.B. PDF)
      mit dem entsprechenden Header aus

ODER

b) leitet per header(location:$umleitung=nach) weiter.

Jetzt will ich aber noch mehr ;)

Das angeforderte Dokument kann nun ein lokales z.B. PDF sein.
Ich möchte gerne eine entfernete URL schützen. Mir ist klar,
dass das nicht wirklich geht, aber ich möchte weingstens die
URL geheim halten ;)

Angenommen:

"http://extern.net/service1.php" soll "geheim gehalten werden".
Ich würde den Link statt direkt auf "http://extern.net/service1.php"
auf "/service1/" zeigen lassen. Den Link per mod_rewrite an meinem
wrapper schicken:

wrapper.php?angefordertes=dokument&umleitung=nach

in $dokument stünde dann "http://extern.net/service1.php"
und der wrapper soll den Inhalt ausgeben (nicht dahin
weiterleiten), nachdem er die Überprüfung vorgenommen hat.

das ginge natürlich mit etwas wie:

echo "<frameset ..." usw.

ist ja aber nicht so schön ;)

hat jemand ne bessere idee ?

beste gruesse,
martin

Jetzt
      header.

[ChrisB]

Hi,

Ich möchte gerne eine entfernete URL schützen. Mir ist klar,
dass das nicht wirklich geht, aber ich möchte weingstens die
URL geheim halten ;)

Angenommen:

"http://extern.net/service1.php" soll "geheim gehalten werden".
Ich würde den Link statt direkt auf "http://extern.net/service1.php"
auf "/service1/" zeigen lassen.

Also willst du eigentlich deinen Webserver als Proxy agieren lassen.

Den Link per mod_rewrite an meinem
wrapper schicken:

wrapper.php?angefordertes=dokument&umleitung=nach

in $dokument stünde dann "http://extern.net/service1.php"
und der wrapper soll den Inhalt ausgeben (nicht dahin
weiterleiten), nachdem er die Überprüfung vorgenommen hat.

das ginge natürlich mit etwas wie:

echo "<frameset ..." usw.

ist ja aber nicht so schön ;)

hat jemand ne bessere idee ?

Na ja, PHP kann ja auch externe Ressourcen einlesen ...

MfG ChrisB

[Martin Hein]

Hi,

Na ja, PHP kann ja auch externe Ressourcen einlesen ...

Das scheitert an relativen Pfaden. Man könnte natürlich anfangen,
den externen Content zu parsen, aber ich glaub das führt dann ins
Ad Absurdum.

Ich hab eigentlich garnichts gegen Framesets. Allerdings
ist das nach meinem Wissen nicht mehr barrierefrei.

schönen Abend,
martin

[ChrisB]

Hi,

Na ja, PHP kann ja auch externe Ressourcen einlesen ...

Das scheitert an relativen Pfaden. Man könnte natürlich anfangen,
den externen Content zu parsen, aber ich glaub das führt dann ins
Ad Absurdum.

Sorry, ich hatte dich so verstanden, dass es dir immer noch lediglich um den Download extern liegender PDF-Dokumente ueber deine Domain geht.

MfG ChrisB

[Cheatah]

Hi,

Ich frage mich, wie das bei meiner "Strato-Rechnung online" geht.
Wahrscheinlich werden die PDFs erst beim Aufruf erstellt.

ja, das ist absolut richtig. Und zwar wird die PDF-_Ressource_ beim Aufruf erstellt - beispielsweise indem der Server eine entsprechende, vorliegende PDF-_Datei_ nimmt und sie mit den passenden HTTP-Headern ausstattet. An dieser Stelle kann natürlich nur spekuliert werden; eine Möglichkeit, dies von außen zu beurteilen, existiert nicht. Aber warum machst Du es nicht ebenso: Erstelle aus einer vorliegenden PDF-Datei eine PDF-Ressource, nachdem Du mittels einer Dir günstig erscheinenden Technik (z.B. PHP) die Legitimierung des Zugriffs überprüft hast. Das einzige, was Du dazu tun musst (da Du den Login-Mechanismus an sich ja schon hast), ist die betreffenden Requests auf ein PHP-Script zu richten, was etwa mit mod_rewrite kein nennenswertes Problem darstellt, und aus dem Script heraus die Datei mit den richtigen Headern zu versehen und zurückzusenden.

Cheatah