問題があります。URL パラメータを使用してデータをクエリする場合、データは ID を使用してクエリされます。
たとえば、注文の詳細をクエリする場合、ID は注文詳細テーブルの ID になります。< /p>
「http://localhost/index/order/detail/id/3.html」
では、この ID を変更して他の人の注文の詳細を照会することはできますか?
注文の詳細を作成するときに、それがこの顧客からの注文であるかどうかを判断する必要がありますか?毎回判断するのは面倒ですか？
または注文番号を使用してクエリしますか?
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
ID がバックグラウンドに渡されると、データベース クエリは id=id の条件をクエリするだけでなく、ユーザーのログインの UID やセッションに保存されているユーザー アカウントなどの多くの条件も取得します
もちろん、SQL インジェクションを防ぐために何かをしたほうがよいでしょう。もし人々が id=1"; の形式で SQL にアクセスした場合、あなたの SQL は非常に危険になります。権限の問題はバックエンドによって判断される必要があります。論理的に言えば、フロントエンドは注文 ID をサーバーに渡す必要があり (ここで URL パラメーターを渡します)、その後バックエンドがテーブルを検索してデータをフロントエンドに返します。 。アクセス許可の問題に関しては、バックエンドは、フロントエンドからインターフェイス呼び出し情報を受信した後、ユーザーがこのインターフェイスを呼び出すアクセス許可を持っているかどうかを最初に判断できます。そうであれば (論理データが適切であるなど)、データは次のようになります。そうでない場合は、このようにアクセスが制御されていないことを直接返します。
実際の順序は混乱を招くため、リクエストは実際にはデータテーブルの主キーフィールドではないため、自分で変更する必要があります
注文の詳細を表示するには、注文 ID と現在のユーザー ID という少なくとも 2 つのパラメータが必要です。バックエンドは、まずこれら 2 つのパラメータを正しく受信したかどうかを判断し、次に注文 ID に基づいて対応する注文情報を見つけ、現在のユーザー ID を注文情報内の注文ユーザー ID と照合する必要があります。それらが矛盾している場合は、アクセス権がないことを示すプロンプトが表示されます。
1. uuid など、同じ ID を注文クエリのベースとして使用することはできません。
2. 注文テーブルには、クエリ時にこの条件を含めます。
ユーザーUIDとオーダーIDの関係は&&です。
注文を確認するときは、次のようにする必要があります:
リーリー1. まず、ユーザーがログインしているかどうかを判断し、セッションを取得して、ユーザー ID に基づいて注文の詳細にアクセスする権限があるかどうかを判断します。