web-dev-qa-db-ja.com

PHPフォーラムシステムを新しいDjango Webサイトと統合する方法

新しいDjango Webサイト（RedHat EL4、Apache 2.0.52、Django 1.1、mod_wsgi）を立ち上げ、基本的な静的から移行しようとしています- htmlおよびphpサイト。現在構成されているため、Djangoは、サイトルートから始まる新しいサイトでのすべてのリクエストを処理します（つまり、mydomain.com /はDjangoによって処理されます）。

古いサイトでは、mydomain.com/forum /にPhpBBフォーラムが設定されていました。フォーラムシステムを新しいサイトの同じ場所に配置する方法（またはその場合）を理解しようとしています。したがって、mydomain.com/forums /の下にあるものはすべてPhpBBによって処理され、それ以外はすべてDjangoによって処理されます。

Apacheの「Location」ディレクティブが使用するツールのように感じますが、ApacheドキュメントとGoogleから十分な具体的なアドバイスを得ていません。私はApacheconfファイルにかなり精通していますが、これまでこの種のことをする必要はありませんでした。提案をありがとう。

phpdjangoapache-2.2phpbb
1
Bill

Apache構成で、ホストから次の方法で静的ファイルを提供しています。

  Alias /media /sites/mysite.org/www/media
  <Location /media>
    Order allow,deny
    Allow from all
  </Location>

これにより、ApacheはDjangoに到達する前にエイリアスを処理します。そのディレクトリに対して機能するには、phpを有効にする必要があると思います。

[〜＃〜] update [〜＃〜]以下のGrahamのコメントによる。 http://httpd.Apache.org/docs/current/sections.html#page-header の「WhattouseWhen」セクションを見てください。

いつ使用するか

ファイルシステムコンテナとウェブスペースコンテナのどちらを選択するかは、実際には非常に簡単です。ファイルシステムに存在するオブジェクトにディレクティブを適用する場合は、常にまたはを使用します。ファイルシステムに存在しないオブジェクト（データベースから生成されたWebページなど）にディレクティブを適用する場合は、を使用します。

ファイルシステム内のオブジェクトへのアクセスを制限しようとするときは、絶対に使用しないことが重要です。これは、多くの異なるWebスペースの場所（URL）が同じファイルシステムの場所にマップされ、制限を回避できるためです。たとえば、次の構成について考えてみます。

<Location /dir/>
Order allow,deny
Deny from all
</Location>

リクエストが http://yoursite.example.com/dir/ の場合、これは正常に機能します。しかし、大文字と小文字を区別しないファイルシステムを使用している場合はどうでしょうか。次に、 http://yoursite.example.com/DIR/ をリクエストすることで、制限を簡単に回避できます。対照的に、ディレクティブは、その呼び出し方法に関係なく、その場所から提供されるすべてのコンテンツに適用されます。 （例外はファイルシステムリンクです。シンボリックリンクを使用して、同じディレクトリをファイルシステムの複数の部分に配置できます。ディレクティブはパス名をリセットせずにシンボリックリンクをたどります。したがって、最高レベルのセキュリティを実現するには、シンボリックリンクは次のようになります。適切なOptionsディレクティブで無効にします。）

大文字と小文字が区別されるファイルシステムを使用しているため、これが当てはまらないと考えている場合は、複数のWebスペースの場所を同じファイルシステムの場所にマップする方法は他にもたくさんあることを覚えておいてください。したがって、可能な場合は常にファイルシステムコンテナを使用する必要があります。ただし、この規則には1つの例外があります。このセクションは特定のURLに関係なくすべてのリクエストに適用されるため、セクションに構成制限を設定することは完全に安全です。

1
davey