[apache] mit mod-rewrite verzeichnis schützen?

[mike]

Hi.

ich mach mir gerade gedanken, wie ich ein verzeichnis mit pdf dokumenten am elegantesten rechtemässig schützen soll.

Voraussetzung: user haben je nach anmeldedatum auf gewisse PDF Dokumente downloadzugriff. Diese liegen in einem bestimmten Verzeichnis (Verzeichnissturuktur?) und es können durchaus mehr PDF dort liegen, als der User einsehen darf.

also ansich hab ich mir das so gedacht:
- von der page aus: Link auf das PDF geht vorab auf eine Validierungsseite, die abprüft, ob der User überhaupt berechtigt ist sie downzuloaden. wenn ja, dann redirect. wenn nein, dann auf Loginseite. soweit so gut.

Problem: Direkter Link auf die Verzeichnisstruktur der PDF Dokumente. Also z.B.: www.website.com/pdf/superdoku.pdf
Auch dann soll eine Validierung erfolgen.

1. Ansatz: mit htaccess das Verzeichnis soweit zuzumachen, dass nur noch der inet-Dienst reindarf und somit nur über die Website ein Download möglich ist. unschön aber wirksam.

2. Ansatz: via htaccess und mod-rewrite, wenn www.website.com/pdf/superdoku.pdf eingegeben wird, einfach auf die Validierungsseite umleiten und abchecken, ob der user den Download durchführen darf...
Fragen:
- geht das? (wenn ja, wie?)
- ist das sicher genug?

thx im voraus.

[Radoo.de]

.

[mike]

hi christoph
gaanz im geheimen hab ich gehofft, dich mit dem titel zu ködern. gelungen

zu deinem vorgehen. in groben zügen hab ich es so geplant und werde es auch so durchführen.


Ich würd es aber so machen:
RechteStufen:
1.) Uploader / Admin (Du?)
ja - über weboberfläche mehrere Redakteure

2.) User - Normal
guest - darf gar nix downloaden

3.) SuperUser (Kunde? Kann alles sehen)
kann nicht alles sehen - nur den Abozeitraum

Aktionen:
A.) Uplaod - per PHP
si

A 1. rename file zu <zufallsname>.pdf (siehe Funktion _getUniqueID() )
noch nicht definiert - wahrscheinlich eine laufnummer (nl1203.pdf...)

A 2. Insert Startname, Zufallsname, Uplaoddatum in tblFiles
ja

B.) Create new User
ebenfalls über web - zeitraum wird dann festgelegt, wenn erste zahlung eingelangt -> 1 Jahr

B 1. Insert user, rechtegruppe, datum into tblUser
jo


C.) download.php
C 1. Auth mittels Cookie/Session etc. wie üblich
is bereits implementiert

C 2. select user_since from user where user=loginName
C 3. SELECT id, startname from tblFiles where uplaoded_at >= user_since
C 4. Loop zur Ausgabe einer Tabelle
2,3,4 genau so geplant


D.) download.php?action=download=<id>
auch so geplant
D 1. Paranoia: Auth user again

nö. hier sollte das download.php bereits den mainpart übernommen haben und auf berechtigung gecheckt haben.
wär das implizit oder soll sich der user da wirklich nochmal mit user/pw anmelden?

D 2. Select startName from tblFiles where id=$id

D 3. Kontruiere PHP-Download mit 'save_as_name' = startName
.........(zur Problematik der pdfs-Dateien siehe auch dclp-faq.de)
.........(dort ist auch Beispielscode für eine solche Umbenennung)

2,3 sehe ich nicht die notwendigkeit. Lass mich aber auch vom Gegenteil überzeugen


Problem bei der Lösung ist imho, wenn jemand den Pfad der pfds rausfindet bzw. wenn direkt auf das Dokument zugegriffen wird.

da hab ich jetzt eh schon soweit eine idee:
RewriteEngine on
RewriteRule .(pdf)$ http://localhost/index.php [R,L]

problem dabei ist, wenn ich einen rewrite auf das betreffende dokument mache, dann springt mir die regel auch wieder an und ich lande wieder auf der startseite

gibt es eine möglichkeit um eine konstellation wie folgt in einer regel zu definieren?

webroot/
index.php
/newsletter/
download.php
nl1.pdf
nl2.pdf
nl3.pdf
...

ich komm vom index.php auf download.php dieser validiert und schickt z.b. den nl1.pdf zum download/anzeige

aber
webroot/newsletter/nl1.pdf -> schickt mich auf download.pdf?

zweiteres passt schon. nur zieht die regel halt immer


zu der offroot sache: hört sich interessant an. ich werde mir mal die scripts anschauen.
Melde mich wieder.

[Radoo.de]

.

[mike]

hi.
habs mal ansatzweise so probiert, wie du mir vorgeschlagen hast.
problem:
der bursche gibt mir keinen download, sondern baut das pdf als txt auf:

siehe: www.dynamicdesign.at/concept/download.php
(handle wird statisch übergeben)

komischerweise liefert mir das script aber eine Datei die so ausschaut:
dateiname.pdf.php (! )

ich hab mal deinen contenttyp auf
header("Content-Type: x-application/octet-stream");
und
header("Content-Type: x-application/pdf");
umgebaut. nix hilft. bin ein wenig ratlos. vielleicht is es auch schon ein bissl spät heut



nochwas: (aus php.net)
Anmerkung: Der Microsoft Internet Explorer 4.01 hat einen Bug, der diese Funktionalität verhindert, und es gibt keinen Workaround. Auch in Microsoft Internet Explorer 5.5 existiert ein Bug, der dies behindert, dieser kann jedoch mittels einem Upgrade auf Service Pack 2 oder neuer behoben werden.

mal davon abgesehen, dass mir der 4.01er keine Sorgen bereitet, ist es der 5.5 der auf alle Fälle funktionieren sollte. schon erfahrung damit gemacht?

[Lars]

Original geschrieben von Longfang

header("Content-Type: x-application/pdf");

Nix da, alter Mann. So ist's richtig:

PHP-Code:

header("Content-type: application/pdf") // kein "x-" 


[Radoo.de]

.

[mike]

ich glaub, das problem liegt wo ganz anders:

folgender reproduzierbarer fehler:
klasse von radoo standalone (ohne mysql usw...)-> download funktioniert

PHP-Code:

header("Content-Type: application/pdf");
header("Content-Disposition: attachment; filename=\"blabla.pdf\"");
readfile("blabla_neu.pdf"); 


baut man einen session_start(); vor dem Header schiess ich genau in diesen Fehler -> php-bug?

Da ich aber zur uservalidierung nicht auf die session verzichten, hab ich dann diese Lösung gefunden:

PHP-Code:

header("Pragma: public");
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header("Content-Type: application/pdf");
header("Content-Disposition: attachment; filename=\"blabla.pdf\"");
readfile("blabla_neu.pdf"); 


erste Feldversuche sind vielversprechend
und es is egal welchen content-typ ich dann angeb (auch leberwurst )

[Radoo.de]

.

[Lars]

Original geschrieben von Longfang
baut man einen session_start(); vor dem Header schiess ich genau in diesen Fehler -> php-bug?

Ich würd da aher auf das ganz normale Verhalten bzgl. dem Senden von Header-Informationen tippen. Von daher also eher kein Bug, oder?

[Radoo.de]

.

[Stuck Mojo]

Hi !!

Ich misch jetzt auch mal mit

PHP-Code:

                        if(isset($HTTP_ENV_VARS['HTTP_USER_AGENT']) and strpos($HTTP_ENV_VARS['HTTP_USER_AGENT'],'MSIE 5.5'))
                                Header('Content-Type: application/dummy');
                        else
                                Header('Content-Type: application/octet-stream');
                        if(headers_sent())
                                $this->Error('Some data has already been output to browser, can\'t send PDF file');
                        Header('Content-Length: '.strlen($this->buffer));
                        Header('Content-disposition: attachment; filename='.$file);
                        header('Expires: 0');
                        header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
                        header('Pragma: public');
                        echo $this->buffer; 


Das ist ein Snippet aus meinem Script bzw. einer modifizierte PDF-Klasse. Der IE hat u.A. Probleme mit einer https-Verbindung. Fixen funzt mit den Pragma-Header.

Vielleicht hilfts ja Im IE5.5 funzts auf alle Fälle.
Wegen Session-Problemen könntest du mal folgendes ausprobieren:

PHP-Code:

session_cache_limiter('private'); 


...das vor session_start()

Gruss
Jan

[mike]

@lars: verstehe ich nicht. session_start sollte eigentlich nix ausgeben. hab das verhalten auch, wenn ich mögliche meldungen unterdrücke (@session_start())

@christian: ich verwende gar kein array, ich gebe dem header direkt den filenamen mit (testweise).

mit dem ns funktioniert das ganze. scheinbar dürfte es sich wirklich um einen ie-bug handeln.

hab leider jetzt keinen zugriff auf den server, aber ich werde am Abend ein Update drüber machen. Dann schaumer weiter

@ 16 Studen: die schaff ich z. Z. auch nicht - bin auf ca. 18 Stunden

[Lars]

Original geschrieben von Longfang
@lars: verstehe ich nicht. session_start sollte eigentlich nix ausgeben. hab das verhalten auch, wenn ich mögliche meldungen unterdrücke (@session_start())

Die Fehlermeldung zu unterdrücken ist die eine Sache, aber wenn die Session-Limiter bereits gesendet sind, könnte sich das doch mit den Headern für den Filestream in die Quere kommen? Oder nicht?

[mike]

du fragst sachen

also ich habs jetzt mal mit output-buffering probiert. nada.

einzig der weg mit den beiden zusätzlichen headern lässt mir die files auch mit dem IE runterladen


nachtrag:
@lars: lagst scheinbar goldrichtig:

zum einem: mein Fehler ist nicht unbekannt:
http://bugs.php.net/bug.php?id=20025

zum anderen ist da auch ein Workaround:

PHP-Code:

session_cache_limiter('public'); 
session_start(); 


so gehts auch ohne die beiden zusätzlichen headers.

wieder was dazugelernt