問題があります。URL パラメータを使用してデータをクエリする場合、データは ID を使用してクエリされます。
たとえば、注文の詳細をクエリする場合、ID は注文詳細テーブルの ID になります。< /p>
「http://localhost/index/order/detail/id/3.html」
では、この ID を変更して他の人の注文の詳細を照会することはできますか?
注文の詳細を作成するときに、それがこの顧客からの注文であるかどうかを判断する必要がありますか?毎回判断するのは面倒ですか?
または注文番号を使用してクエリしますか?
给我你的怀抱2017-05-16 13:03:46
ID がバックグラウンドに渡されると、データベース クエリは id=id の条件をクエリするだけでなく、ユーザーのログインの UID やセッションに保存されているユーザー アカウントなどの多くの条件も取得します
仅有的幸福2017-05-16 13:03:46
権限の問題はバックエンドによって判断される必要があります。論理的に言えば、フロントエンドは注文 ID をサーバーに渡す必要があり (ここで URL パラメーターを渡します)、その後バックエンドがテーブルを検索してデータをフロントエンドに返します。 。アクセス許可の問題に関しては、バックエンドは、フロントエンドからインターフェイス呼び出し情報を受信した後、ユーザーがこのインターフェイスを呼び出すアクセス許可を持っているかどうかを最初に判断できます。そうであれば (論理データが適切であるなど)、データは次のようになります。そうでない場合は、このようにアクセスが制御されていないことを直接返します。
PHPz2017-05-16 13:03:46
注文の詳細を表示するには、注文 ID と現在のユーザー ID という少なくとも 2 つのパラメータが必要です。バックエンドは、まずこれら 2 つのパラメータを正しく受信したかどうかを判断し、次に注文 ID に基づいて対応する注文情報を見つけ、現在のユーザー ID を注文情報内の注文ユーザー ID と照合する必要があります。それらが矛盾している場合は、アクセス権がないことを示すプロンプトが表示されます。
曾经蜡笔没有小新2017-05-16 13:03:46
1. uuid など、同じ ID を注文クエリのベースとして使用することはできません。
2. 注文テーブルには、クエリ時にこの条件を含めます。
PHPz2017-05-16 13:03:46
1. まず、ユーザーがログインしているかどうかを判断し、セッションを取得して、ユーザー ID に基づいて注文の詳細にアクセスする権限があるかどうかを判断します。