Home / server / Questions / 177242
Accepted
Bill
Asked: 2010-09-03 00:01:48 +0800 CST

How to integrate PHP forum system with new Django website

  • 772

I'm just about to launch a new Django website (RedHat EL4, Apache 2.0.52, Django 1.1, mod_wsgi), transitioning from a basic static-html and php site. As it's currently configured, Django handles every request on the new site, starting from the site root (i.e. mydomain.com/ is processed by Django).

The old site had a PhpBB forum set up at mydomain.com/forum/. I'm trying to figure out how (or if) I can get the forum system to live in the same place on the new site. So, anything under mydomain.com/forums/ is handled by PhpBB and everything else is handled by Django.

I feel like the Apache 'Location' directive is the tool to use, but I'm not getting enough specific advice from the Apache docs and Google. I'm reasonably familiar with Apache conf files, but I haven't had to do this type of thing before. Thanks for any suggestions.

php apache-2.2 django phpbb

1 Answers

  1. Best Answer

    I have static files served from my host via the following in my apache config:

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

    With that, Apache deals with the alias before it ever gets to Django. I assume you will just need to have php enabled for it to work against that directory.

    UPDATE As per Graham's comment below. Look at the "What to use When" section in http://httpd.apache.org/docs/current/sections.html#page-header

    What to use When

    Choosing between filesystem containers and webspace containers is actually quite easy. When applying directives to objects that reside in the filesystem always use or . When applying directives to objects that do not reside in the filesystem (such as a webpage generated from a database), use .

    It is important to never use when trying to restrict access to objects in the filesystem. This is because many different webspace locations (URLs) could map to the same filesystem location, allowing your restrictions to be circumvented. For example, consider the following configuration:

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

    This works fine if the request is for http://yoursite.example.com/dir/. But what if you are on a case-insensitive filesystem? Then your restriction could be easily circumvented by requesting http://yoursite.example.com/DIR/. The directive, in contrast, will apply to any content served from that location, regardless of how it is called. (An exception is filesystem links. The same directory can be placed in more than one part of the filesystem using symbolic links. The directive will follow the symbolic link without resetting the pathname. Therefore, for the highest level of security, symbolic links should be disabled with the appropriate Options directive.)

    If you are, perhaps, thinking that none of this applies to you because you use a case-sensitive filesystem, remember that there are many other ways to map multiple webspace locations to the same filesystem location. Therefore you should always use the filesystem containers when you can. There is, however, one exception to this rule. Putting configuration restrictions in a section is perfectly safe because this section will apply to all requests regardless of the specific URL.

    • 1