私があなたをよく理解しているなら:
エンドユーザーにいくつかのURLを提供したい:
/profile.php?id=<id>&hash=<hash>
/<nickname>
それらはすべて利用可能ですが、2番目のものが好ましい方法です。
ニックネームが「foo/bar」、「index.php」、「admin」などの場合、URLのタイプに問題があり/<nickname>
ます。問題は、一部のニックネームが他の有効なURLをカバーしている可能性があることです。したがって、少なくともバニティURLのより適切な形式は次のようになります。
/nick/<nickname>
また/user/<nickname>
ニックネームが他のアセットへの有効なパスと一致しないようにする必要がある場合は、それを確認する必要があります。
次に、ニックネーム、スペース、「/」、中国語のutf16文字、Windows固有のエンコーディングなどの特殊文字を処理する必要があります。これは通常、ニックネームを処理して実際のユーザーページを見つけるための最適なツールとしてアプリケーションサーバーを対象としています。表示します。
ここで、最初のURL形式を取り戻しましょう: /profile.php?id=<id>&hash=<hash>
、ハッシュを使用して、IDを変更することでユーザープロファイルに直接アクセスしないようにします。そして、あなたはすべてのユーザーがニックネームを持っていると言いました。単にバニティフォーマットを使用し、IDを使用してprofile.phpスクリプトに直接アクセスすることを禁止しないのはなぜですか?すべてのユーザープロファイルアクセスを内部で処理し、そのようなエントリを提供しないようにすることができます...とにかく、IDでユーザープロファイルにアクセスできるようにしたい場合を考えてみましょう。
このアクセスURLは、アプリケーションによって生成されます。アプリケーションは、リンクを提供するときにURLの後にハッシュを追加しています(おそらく、ハッシュはニックネームに基づくソルトハッシュですか?)。したがって、アプリケーションはユーザーごとにユーザーハッシュを保存できます。そして、profile.phpでは、ハッシュがこのIDに適していることを常に確認します。これはすべて、httpサーバー(Apache)ではなく、アプリケーションで管理されます。httpサーバーと彼の書き換えツールは、私の謙虚な意見では、一致させるための適切なツールではありません。送信リンクを簡単に一致させて変更することはできません。進行中のリンクを簡単にキャッチして、適切なprofile.phpに変換することはできません。 + id+hashフォーム。
したがって、私が使用する唯一のrewriteRuleは、ニックネームベースのエントリをキャッチし、それらをアプリケーションのプロファイルリダイレクタスクリプトに内部的に送信することです。何かのようなもの:
RewriteRule ^/nick/(.*)$ /profile-by-nick.php?nick=$1 [L,QSA]
次に、このphpスクリプト内で、profile.phpと同じタスクを提供したいことを実行できます。適切に記述されたphpアプリを使用すると、アプリケーション内で内部リダイレクトを提供するのは非常に簡単です。profile.phpスクリプトで実際のhttp302リダイレクトを送信しないでください。関数、クラスなどを使用します。
本当にapacheが正しいprofile.php?id =&hash = urlをアプリケーションに直接送信したい場合(おそらくあなたのphpコードがponeyによって書かれたため:-))、@DavidRavettiによって提案されたようにRewriteMapをチェックしてデーモンとして実行され、apacheへのニックネーム-> id+hashマッピングを提供する外部スクリプト。しかし、それを処理するのに適切な場所ではなく、実際にはもっと複雑に思えます。このスクリプトには、データベースをロードする権限と、アプリケーションにすでにあるテーブル構造に関する情報が必要です。