最新のWebアプリケーションでは、単一のエントリポイントの概念を使用するのが一般的です。 この概念は、アプリケーションサーバーへのすべての要求が1つのファイルにリダイレクトされるという事実に要約されます。このファイルは、要求パラメーターに基づいて、スクリプトのさらなる動作を調整します。 このようなアプローチは、コードの冗長性が大幅に減少するため、作成段階とプロジェクトサポートの段階の両方で大きな利点をもたらします。動的コンテンツを操作するアプリケーションの場合、単一のエントリポイントが唯一の正しい決定です。
上記の例は、Apache Webサーバーの構成に関連しています。
実装の単一のエントリポイントの概念は、Webサーバーにすべてのリクエストをファイルにリダイレクトするように指示する必要があるという事実に基づいています。これは、唯一のエントリポイントになります。たとえば、アプリケーションルートディレクトリのindex.phpファイルになります。 これらの目的のために、Apache Webサーバーにはmod_rewriteモジュールにあるRewriteRuleディレクティブがあります。 ディレクティブの構文は次のとおりです。
RewriteRuleパターンは、現在のURLに適用されるperl互換の正規表現であり、現在はこのルールが適用される時点のURLです。 このURLは、最初に要求されたURLと必ずしも一致しません。これまで、このURLには他のルールが既に適用され、それに応じて変換されていた可能性があるためです。
置換は、パターンに一致する元のURLを置き換える文字列です。 テキストに加えて、置換で多くのものを使用できますが、これまでのところ、REQUEST_URIサーバー変数のみに関心があります。
フラグのうち、使用するのはQSAとLの2つだけです。最初は、ルックアップ文字列で、URLから既存のクエリ文字列へのクエリ文字列を置き換えるのではなく、追加する必要があるものを変換メカニズムに示します。 Lフラグは、この時点で変換プロセスを停止し、変換ルールを適用しないようにサーバーに指示します。
上記のすべてを考慮して、アプリケーションのルートディレクトリにある.htaccessファイルに次の行を追加します。
RewriteRule ^(.*)$ index.php?%{REQUEST_URI} [QSA,L]ただし、スクリプトに直接アクセスすることに加えて、ブラウザーはカスケードスタイルシート、画像、スクリプトファイルなど、サーバーからさまざまなリソースファイルを要求することを忘れないでください。 サーバーがブラウザーに目的のアクセスを許可するには、RewriteRuleディレクティブに追加の条件を設定する必要があります。 これらの条件は、RewriteCondディレクティブによって記述されます。RewriteCondディレクティブは、いつURLに変換するか、またはいつ変更しないままにするかを決定します。
詳細に深く入り込むことなく、いくつかの例を示します。言及されたディレクティブの詳細については、記事の最後にあるリンクを参照してください。
RewriteCond %{REQUEST_URI} !^\/resources/styles/(.*).cssRewriteCond %{REQUEST_URI} !^\/resources/images/(.*).pngRewriteCond %{REQUEST_URI} !^\/resources/images/(.*).jpgRewriteCond %{REQUEST_URI} !^\/resources/lib/jquery/(.*).js上記の行を見ると、REQUEST_URIがperl互換の正規表現で記述された行と比較されていることがすぐにわかります。偶然の場合、URLスプーフィングは発生しません。
注：RewriteRuleを使用する前に、すべてのRewriteCondディレクティブを記述する必要があることに注意してください。
上記の方法は、可能性の1つに過ぎず、コンセプトがZend Frameworkにどのように実装されるかを考えてみましょう。前の例では、エントリポイントがWebアプリケーションのルートディレクトリにあると仮定しましたが、Zend Frameworkに基づくデフォルトのプロジェクト構造は、共有ディレクトリレベルを下げると、デフォルトではその名前はpublicになり、Webアプリケーションへのアクセスは、パブリックディレクトリがアプリケーションのルートになるように構成されます。 パブリックディレクトリの外部にあるリソースにアクセスするには、スクリプトは条件付きアドレス指定を使用してより高いレベルに戻るか、絶対アドレス指定を使用する必要がありますが、これはまったく便利ではありません。次のようにすることができます。
define( 'DIR_SEPARATOR ', '/' ); define( 'ROOT', '..' . DIR_SEPARATOR );
したがって、アプリケーションの論理ルートへの相対パスを含む定数を取得しました。
public / .htaccessファイルの内容を書き込むために残っています：
RewriteCond %{REQUEST_FILENAME} -s [OR]RewriteCond %{REQUEST_FILENAME} -l [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^.*$ - [NC,L]RewriteRule ^.*$ index.php [NC,L]説明したアプローチを使用すると、アプリケーションのパブリックリソースに特定のアクセス権を設定する必要がなくなります。それらをパブリックディレクトリに配置するだけで、アクセスが自動的に許可され、パブリック以外のアプリケーションスクリプトファイルへのアクセスが閉じられます。
mod_rewriteモジュールのドキュメント