ダウンロード可能なPDF請求書を保存するのに最適な場所はどこですか?


7

私のコンポーネントは、顧客がダウンロードできるPDF形式の請求書を作成します。

これらのファイルを保存するのに最適な場所はどこですか?

/adminitrator/componentes/com_mycomponent/invoices

/componentes/com_mycomponent/invoices

/media/com_mycomponent/invoices

権限のないユーザーがこれらのファイルを直接ダウンロードするのを防ぐにはどうすればよいですか?

顧客が他の人の請求書をダウンロードできないようにするにはどうすればよいですか?

回答:


7

私は使用しないようにアドバイスします

administrator/components/com_mycomponent/invoices 

これは.htaccess、管理者ディレクトリでを使用すると問題が発生する可能性があるためです。たとえば、Akeeba管理ツール

メディアフォルダーも使用したいと思います。

次のような適切な元の名前でハッシュファイルを提供することもできます。

<?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

これはあなたの質問に直接答えないかもしれませんが、この質問について別の見方をしたいと思います。

私がしようとするだろうあなたが生成できる可能性が収納書類限り避けます。理由:後で変更するのが難しいフォルダー名/ファイル名を決める必要があります。スペースを使いすぎて、セキュリティ上の問題が発生する可能性があります。

もちろん、これはアプリケーションの動作に依存しますが、理想的には、データベーステーブルに請求書データを入れ、必要に応じてオンザフライで請求書を生成します。

私の2セント。


2
それらをその場で生成 <<素晴らしいアイデア
Lodder

関連する考慮事項として、変化する可能性のある情報を動的にプルする場合(たとえば、ユーザー名を使用)、「静的」PDFを使用すると、変更を行うのではなく、特定の時点のレコードを取得できます。現在、私たちはeラーニングシステムに取り組んでおり、私たちが生成する証明書は、合格したときに名前が必要です(そのため、人々は単に名前を変更して、合格していない友人のために新しい証明書を生成できます)。 。ちょっとした考え。
codehands 2015年

@codinghands-この場合、データベース内のPDFの名前を名前ではidなくユーザーに関連付けます。発電時には、あなたがし合っているでしょうidに対するテーブル内idでの#__usersユーザー名または完全な名前を取得するにはテーブルと、それはサーバースペースの地獄の量節約のように)全体的に私はずっとこの方法を好む
Lodder

名前をPDFに印刷する必要がある場合、DBでPDFを何にリンクするかは問題ではありません。名前が変更された場合、証明書(動的な場合)も変更されます。回。
codinghands

名前は、あなたが言及した理由のために請求書テーブルにハードコーディングするため、変更されません。請求書では、このような情報にテーブルの関連付けを使用しないでください。
Valentin Despa 2015年

5

私は自分の2セント(ファイル名のハッシュにいくつかの良い点)を投入すると思いました。

最近、同様の問題が発生しました。を心配する代わりに、パスを指定するコンポーネントパラメータを.htaccess使用して上記のファイルを保存しpublic_html、次にPHPを使用しreadfileてPDFをフェッチして出力します。

すべてのホストで動作するわけではありませんが、ほとんどのアプリケーションでは比較的手間がかからず、ホットリンクやその他のアクセスを完全に防ぎます。


3

ユーザーが生成したファイルをコンポーネントディレクトリに保存しないでください。コンポーネントの更新中に(適切に行われなかった場合)、またはユーザーがコンポーネントをアンインストールしたときに、それらを失う可能性があります。

そのようなファイルを保存する正しい場所は、実際には「イメージ」フォルダです。これは、ユーザーがメディアマネージャを使用してファイルを簡単に管理できる場所です。「メディア」フォルダも実行可能な選択肢の1つですが、実際にはCSS、JSなどの拡張アセットを保持するためのものです。

ただし、ファイルに誰にも公開されてはならない機密データが含まれている場合は、これらのフォルダーに保存することはお勧めできません。あなたがそれらをハッシュしたとしても、誰かが最終的にそれらを読むことができると確信することができます。

安全にする必要がある場合は、ファイルをまったく保存せず、要求に応じて動的に生成します。または、webrootの外に保存し、PHPを使用してアクセスします。他に安全な方法はありません。


You may end up loosing them during an update of your component>>更新スクリプトで指定しない限り、ディレクトリに保存されているファイルは削除されないと思います。アンインストールに同意する
Lodder

1
あるリリースのマニフェストXMLで指定されていたフォルダーが更新中に自動的に削除され、後のリリースで削除された場合。
Bakual

2

次のディレクトリをすべての請求書のルートとして使用しても問題ありません。

administrator/components/com_mycomponent/invoices

ただし、請求書が生成されたら、ファイル名をハッシュ化することをお勧めします。そのようです:

administrator/components/com_mycomponent/invoices/HASHED_FILE.pdf

または、請求書ごとに、ハッシュされたディレクトリを作成し、次のようにPDFをそこに保存します。

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

更新:

この方法を選択した場合、htaccessファイルを使用して直接アクセスを防止し、PHPによるこれらのPDFファイルへのアクセスのみを許可できます。

PHP駆動型のダウンロードの場合、ユーザーのIDとともに、ハッシュをデータベースの表形式で保存することをお勧めします。ファイルのダウンロードがリクエストされたときに、保存したIDと現在ログインしているユーザーのIDを照合し、データベースに保存されているハッシュと照合することができます。


@downvoter、ステップアップ、自分を示し、なぜ私が書いたことが間違っていると思うのかを説明してください
Lodder

ユーザーが生成したファイルをコンポーネントディレクトリに保存しないでください。また、ハッシュだけでは安全にアクセスできません。少しだけ難しいです。アクセス制限が必要な場合は、ベールだけでなく制限する必要があります。それは誤った安心感を与えるでしょう。
Bakual

@Bakual-htaccessファイルを使用して、ファイルへの直接アクセスを防ぎ、PHP経由でのアクセスのみを許可することができます
Lodder

それでも、コンポーネントディレクトリ内にそれらを格納するのは適切ではありません。imagesmediaまたはwebroot外のフォルダを使用します。
Bakual

2

私にとって、その目的に最も適したメディアフォルダ。直接アクセスを制限するには、以下の内容で.htaccessファイルをフォルダーに作成します。

DENY FROM ALL

反対票を投じる理由はありますか?答えを使って何が間違っている場合してくださいコメント...
Nagarjun

「どこかの場所」が間違っているからです。ファイルをコンポーネントディレクトリに保存しないでください。
Bakual

それはどうして間違っているのでしょうか?それを言うルールはありますか?コンポーネントディレクトリにファイルを保存することはお勧めしません。更新パッケージに同じファイルが含まれていると上書きされ、問題が発生しないためです。コンポーネントをアンインストールしない限り、コンポーネントディレクトリに問題はありません。そして、私はメディアフォルダーとしての私の好みを明確に述べました。
ナガルジュン2015年

こちらの「ベストプラクティス」で説明されています:docs.joomla.org/Development_Best_Practices
Bakual

まあ..ドキュメントの名前は、上記の意味を説明しています。とにかくリンクをありがとう。
Nagarjun
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.