Was ist der beste Ort, um herunterladbare PDF-Rechnungen zu speichern?


7

Meine Komponente erstellt Rechnungen im PDF-Format, die den Kunden zum Herunterladen zur Verfügung stehen.

Wo können diese Dateien am besten gespeichert werden?

/adminitrator/componentes/com_mycomponent/invoices

/componentes/com_mycomponent/invoices

/media/com_mycomponent/invoices

Wie kann ich verhindern, dass nicht autorisierte Benutzer diese Dateien direkt herunterladen?

Wie kann ich verhindern, dass Kunden Rechnungen anderer Personen herunterladen?

Antworten:


7

Ich würde davon abraten

administrator/components/com_mycomponent/invoices 

Dies liegt daran, dass es ein Problem darstellen kann, wenn Sie es .htaccessin Ihrem Administratorverzeichnis verwenden. Zum Beispiel mit Akeeba Admin Tools

Ich würde es vorziehen, auch den Medienordner zu verwenden.

Sie können die Hash-Dateien auch mit den richtigen Originalnamen wie folgt bereitstellen:

<?php
header("Content-type:application/pdf"); 

// It will be called NICE_TITLE.pdf
header("Content-Disposition:attachment;filename='NICE_TITLE.pdf'");

// The PDF source is in HASHED_FILE.pdf
readfile("HASHED_FILE.pdf");
?>

6

Dies beantwortet Ihre Frage möglicherweise nicht direkt, aber ich wollte zu dieser Frage einen anderen Standpunkt vertreten.

Ich würde versuchen, das Speichern von Dokumenten, die Sie generieren können, so weit wie möglich zu vermeiden. Grund: Sie müssen sich für Ordnernamen / Dateinamen entscheiden, die später schwer zu ändern sind. Es kann zu viel Platz beanspruchen und Sicherheitsprobleme verursachen.

Dies hängt natürlich davon ab, wie Ihre Anwendung funktioniert, aber im Idealfall würde ich die Rechnungsdaten in Datenbanktabellen haben und bei Bedarf Rechnungen im laufenden Betrieb erstellen.

Meine zwei Cent.


2
Generieren Sie sie im laufenden Betrieb << tolle Idee
Lodder

Als verwandte Überlegung: Wenn Sie Informationen dynamisch abrufen, die sich ändern können (z. B. unter Verwendung eines Benutzernamens), können Sie mit der 'statischen' PDF-Datei einen Zeitpunkt aufzeichnen, anstatt Änderungen vorzunehmen. Derzeit arbeiten wir an einem E-Learning-System, und die von uns generierten Zertifikate müssen zum Zeitpunkt ihres Bestehens ihren Namen haben (damit die Benutzer einfach ihren Namen ändern und dann ein neues Zertifikat für ihren Freund erstellen können, der das Bestehen nicht bestanden hat). . Nur ein Gedanke.
Codinghands

@codinghands - In diesem Fall würden Sie den Namen der PDF-Datei in der Datenbank ideher den Benutzern als dem Namen zuordnen . Bei der Generierung würden Sie dann die idin der Tabelle mit den idin der #__usersTabelle vergleichen, um ihren Benutzernamen oder vollständigen Namen zu erhalten;) Insgesamt bevorzuge ich diese Methode, da sie eine Menge Serverplatz spart
Lodder

Wenn der Name in der PDF-Datei gedruckt werden muss, spielt es keine Rolle, mit was Sie die PDF-Datei in der Datenbank verknüpfen. Wenn sich der Name ändert, ändert sich auch das Zertifikat (wenn es dynamisch ist), was in dem von mir beschriebenen Anwendungsfall schlecht ist mal.
Codinghands

Der Name ändert sich nicht, da Sie ihn aus dem von Ihnen genannten Grund in der Rechnungstabelle fest codieren. Die Rechnung sollte keine Tabellenzuordnungen für solche Informationen verwenden.
Valentin Despa

5

Ich dachte nur, ich würde meine 2 Cent einwerfen (einige gute Punkte beim Hashing des Dateinamens).

Ich hatte kürzlich ein ähnliches Problem. Anstatt .htaccessmir Sorgen zu machen , speichere ich einfach die obigen Dateien public_htmlmit einem Komponentenparameter, der den Pfad angibt, und verwende dann PHPs readfile, um die PDF-Datei abzurufen und auszugeben.

Funktioniert nicht mit allen Hosts, ist jedoch für die meisten Anwendungen relativ aufwendig und verhindert jegliches Hotlinking oder anderen Zugriff.


3

Speichern Sie niemals benutzergenerierte Dateien in den Komponentenverzeichnissen. Möglicherweise verlieren Sie sie während eines Updates Ihrer Komponente (wenn dies nicht ordnungsgemäß durchgeführt wurde) oder sicher, wenn der Benutzer sie deinstalliert.

Der richtige Ort zum Speichern solcher Dateien ist der Ordner "images". Hier kann der Benutzer die Dateien einfach mit dem Medienmanager verwalten. Der Ordner "Medien" wäre eine weitere praktikable Wahl, aber er ist eigentlich eher dazu gedacht, Erweiterungs-Assets wie CSS, JS und dergleichen aufzunehmen.

Wenn die Dateien jedoch sinnvolle Daten enthalten, die niemandem zur Verfügung stehen sollten, ist es eine schlechte Idee, sie in einem dieser Ordner zu speichern. Selbst wenn Sie sie hashen, können Sie sicher sein, dass irgendwann jemand sie lesen kann.

Wenn es sicher sein muss, speichern Sie die Datei entweder gar nicht und generieren Sie sie stattdessen dynamisch auf Anfrage. Oder speichern Sie es außerhalb von Webroot und greifen Sie mit PHP darauf zu. Es gibt keinen anderen sicheren Weg.


You may end up loosing them during an update of your component>> Ich glaube nicht, dass in einem Verzeichnis gespeicherte Dateien entfernt werden, es sei denn, Sie geben dies im Aktualisierungsskript an. Stimmen Sie der Deinstallation zu
Lodder

1
Ordner werden während eines Updates automatisch gelöscht, wenn Sie sie in einer Manifestversion in Ihrem Manifest-XML angegeben und in einer späteren Version entfernt haben.
Bakual

2

Die Verwendung des folgenden Verzeichnisses als Stammverzeichnis für alle Rechnungen ist völlig in Ordnung:

administrator/components/com_mycomponent/invoices

Ich würde jedoch empfehlen, den Dateinamen zu hashen, sobald die Rechnung erstellt wurde. Wie so:

administrator/components/com_mycomponent/invoices/HASHED_FILE.pdf

Entweder das oder Sie erstellen für jede Rechnung ein Hash-Verzeichnis und speichern die PDF-Datei dort wie folgt:

administrator/components/com_mycomponent/invoices/HASHED_DIR/file.pdf

Aktualisieren:

Wenn diese Methode ausgewählt ist, können Sie eine htaccess-Datei verwenden, um den direkten Zugriff zu verhindern und nur den PHP-gesteuerten Zugriff auf diese PDF-Dateien zuzulassen.

Für einen PHP-gesteuerten Download würde ich empfehlen, den Hash zusammen mit der Benutzer-ID in einer Datenbanktabelle zu speichern. Wenn Sie aufgefordert werden, die Datei herunterzuladen, können Sie die von Ihnen gespeicherte ID mit der ID des aktuell angemeldeten Benutzers abgleichen und natürlich den in der Datenbank gespeicherten Hash abgleichen.


@downvoter, steig auf, zeig dich und erkläre, warum du denkst, was ich geschrieben habe, ist falsch
Lodder

Bitte speichern Sie keine benutzerdefinierten Dateien in Komponentenverzeichnissen. Auch Hashing allein macht den Zugriff nicht sicher. Es ist nur ein bisschen schwieriger. Wenn es Zugriffsbeschränkungen benötigt, muss es eingeschränkt und nicht nur verschleiert werden. Es würde ein falsches Gefühl der Sicherheit geben.
Bakual

@ Bakual - Sie können eine htaccess-Datei verwenden, um den direkten Zugriff auf eine Datei zu verhindern und nur den Zugriff über PHP
Lodder

Es wäre immer noch der falsche Ort, um sie in den Komponentenverzeichnissen zu speichern. Verwenden Sie images, mediaoder einen Ordner außerhalb von Webroot.
Bakual

2

Für mich ist der Medienordner am besten für diesen Zweck geeignet. Um den direkten Zugriff einzuschränken, erstellen Sie einfach eine .htaccess-Datei in Ihrem Ordner mit dem folgenden Inhalt.

DENY FROM ALL

Gibt es einen Grund für eine Ablehnung? Bitte kommentieren Sie, wenn etwas mit der Antwort nicht stimmt.
Nagarjun

Weil "jeder der Orte" falsch ist. Dateien sollten nicht in den Komponentenverzeichnissen gespeichert werden.
Bakual

Wie sollte das falsch sein? Gibt es eine Regel, die das sagt? Es wird nicht empfohlen, Dateien in Komponentenverzeichnissen zu speichern, da sie überlastet werden, wenn die Update-Pakete dieselben Dateien enthalten, da sonst keine Probleme auftreten. Sofern Sie die Komponente nicht deinstallieren, treten keine Probleme mit den Komponentenverzeichnissen auf. Und ich habe meine Präferenz als Medienordner klar angegeben.
Nagarjun

Es wird in der "Best Practice" hier erklärt: docs.joomla.org/Development_Best_Practices
Bakual

Nun ... der Name des Dokuments erklärt, was ich oben gemeint habe. Trotzdem danke für den Link.
Nagarjun
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.