ユーザーがログインして Web アプリケーションのドキュメントにアクセスしている状況について、開発者と友好的な議論をしています。ユーザーが表示できるようにドキュメントをロードすると、セッション内のユーザー ID と、QueryString を介して渡される可能性のある documentID が取得されます。
ユーザーが QueryString の documentID を変更できないようにするために、ドキュメントをロードするストアド プロシージャが UserId をパラメーターとして使用し、ドキュメントに対する権限を検証することを提案します。
私の開発者の友人は、別の手順を実行してページの早い段階でドキュメントへのアクセス権を決定し、ドキュメントを表示する必要があるときにドキュメントを取得する手順を実行することを提案しています。
何か不足していますか？最も効率的で安全なのはどれですか? UserId と DocID を 1 つのプロシージャ コールに渡して、権限を確認し、ドキュメントをプルする方が効率的なソリューションだと思いました。
ドキュメントをロードするストアド プロシージャが UserId をパラメーターとして使用して、ドキュメントに対する権限を検証することを提案します。
これが進むべき道だと思います。それ以外の理由がなければ、より安全です。このプロシージャを再利用して、アクセスを確認するのを忘れると、大きな穴が開いてしまいます。このようにして、アクセス権がない限りドキュメントにアクセスできないことが明らかになり、組み込まれています。
userID はセッション変数である必要があります。右。クエリ文字列で documentID を渡します。うん。
ドキュメントがデータベースに保存されていると仮定すると、パーミッション用のテーブル (recordID、userID、および documentID) が作成されます。伝票を呼び出すときに、このテーブルと結合します。結果が出なければ、書類は届きません。すべてを適切にインデックス化すると、高速になります。
厳密に言えば、パフォーマンスの観点から、UserID を DocumentID と共に 1 つのストアド プロシージャに渡すのが最適です。データベース サーバーへの往復は 1 回だけです。また、他の人が指摘しているように、このドキュメントを他のページまたはアプリケーションから取得する場合、同じストアド プロシージャを使用する場合は、そのためにセキュリティをバイパスしていないことを確認してください。
ただし、専用のセキュリティ検証ストアド プロシージャを用意することが理にかなっているシナリオもあります。ドキュメント以外に保護したい他のリソースがあり、検証コードが簡単でない場合は、データベース内のすべてのストアド プロシージャで検証コードを複製したくない場合があります。その場合、セキュリティ インフラストラクチャをデータ アクセス レイヤーに移動し、要求されたリソースを取得する前に、データ アクセス レイヤーに db 呼び出しを行わせてアクセスを承認させることが理にかなっている場合があります。この方法を取る場合、リソースを要求する前に承認データベース呼び出しを行うことを常に覚えておく必要がある開発者に依存したくありません。