私は現在、さまざまなアクセスレベルがあるWebアプリケーションに取り組んでいます。ユーザーはアプリケーションの一部の領域にアクセスできますが、別の領域にはアクセスできない場合があります。
アプリケーションは次のようなクリーンなURLで構築されています http://mysite.com/projects/newproject1
システムは、ユーザーがアクセスできるものを決定し、それらのアイテムのボタン/メニュー/リンクを作成します。ユーザーは、自分がアクセスできないものへのリンク/ボタンまたはメニューを見ることはありません。
ただし、アプリケーションはクリーンなURLで構築されているため、プロジェクトモジュールまたはプロジェクトモジュールの「newproject1」にアクセスできないはずの誰かが、URLを介してその領域に直接アクセスできます。 URLは別の電子メールで送信される場合もあれば、賢くなってアプリケーションのその領域にアクセスできるかどうかを確認しようとしているだけの場合もあります。
現在、すべての「禁止されたリクエスト」のケースを「ページが見つかりません」エラーとして扱うことを検討しています:
これは良い考えですか?
あなたの質問は本質的に「これは良いアイデアですか?」ですので、いいえ、そうではありません。
ユーザーは「賢くなろうとしている」かもしれないし、実際にはもっと賢いかもしれない。ユーザーがUIデザイナー/ PHP開発者自身の場合はどうなりますか?
404を偽装する場合は、メッセージを両方の方法で解釈できるようにすることをお勧めします。知識のあるユーザーは、これが「キープオフ」の信号であることを理解しますが、世間知らずの訪問者は明らかに「申し訳ありません」と表示します。
彼らがそれを思いついたとき、私は本当にそれが好きでした「 それが私たちが知っているすべてです 」。それの終わりにピリオドで完了します。
まあ、彼らが好奇心が強い、または賢くなろうとしている場合、Webクローラーやそのようなツール、あるいはGooglebotさえあれば、多くの404が表示されますが、それは望みません。 403は「すぐそこに停止」、404は「不運、再試行」のようです。また、善良なユーザーが404だけを表示しているため、アクセスや他の種類の問題があるかどうかを伝えるのは難しいでしょう。
これはバックエンドの答えです。 いいえ良い考えではありません。403と404のページが同じように見えるようにUI側を変更したい場合。
ただし、応答側では、ページが存在するか、ページが禁止されているかを知ることが重要です。
アプリの外観やプロジェクトの目的はわかりませんが、ウェブサイトへのバックエンドクロールを実行するように依頼すると、デバッグ時に404応答が返され続け、これは非常に混乱します私はページが存在しないと思いますので、他の目的を修正してみましょう。ただし、403をスローすると、その時点で正確にわかっています。サーバーが私を許可していません。何か間違ったことをしているに違いありません。
ただし、ユーザーが心配な場合は、403
と混同すると、フロントエンドが404
ページのように見えます。
セキュリティが心配な場合は、403が常に正しいことを確認してください。
ページに「200
が見つかりません」とはっきりと表示されているときに送信されたResponse 404
を見た回数。これはbad badと非常にbad!