diff --git a/django/contrib/auth/handlers/modpython.py b/django/contrib/auth/handlers/modpython.py deleted file mode 100644 index de961fa4dd..0000000000 --- a/django/contrib/auth/handlers/modpython.py +++ /dev/null @@ -1,56 +0,0 @@ -from mod_python import apache -import os - -def authenhandler(req, **kwargs): - """ - Authentication handler that checks against Django's auth database. - """ - - # mod_python fakes the environ, and thus doesn't process SetEnv. This fixes - # that so that the following import works - os.environ.update(req.subprocess_env) - - # apache 2.2 requires a call to req.get_basic_auth_pw() before - # req.user and friends are available. - req.get_basic_auth_pw() - - # check for PythonOptions - _str_to_bool = lambda s: s.lower() in ('1', 'true', 'on', 'yes') - - options = req.get_options() - permission_name = options.get('DjangoPermissionName', None) - staff_only = _str_to_bool(options.get('DjangoRequireStaffStatus', "on")) - superuser_only = _str_to_bool(options.get('DjangoRequireSuperuserStatus', "off")) - settings_module = options.get('DJANGO_SETTINGS_MODULE', None) - if settings_module: - os.environ['DJANGO_SETTINGS_MODULE'] = settings_module - - from django.contrib.auth.models import User - from django import db - db.reset_queries() - - # check that the username is valid - kwargs = {'username': req.user, 'is_active': True} - if staff_only: - kwargs['is_staff'] = True - if superuser_only: - kwargs['is_superuser'] = True - try: - try: - user = User.objects.get(**kwargs) - except User.DoesNotExist: - return apache.HTTP_UNAUTHORIZED - - # check the password and any permission given - if user.check_password(req.get_basic_auth_pw()): - if permission_name: - if user.has_perm(permission_name): - return apache.OK - else: - return apache.HTTP_UNAUTHORIZED - else: - return apache.OK - else: - return apache.HTTP_UNAUTHORIZED - finally: - db.connection.close() diff --git a/django/core/handlers/modpython.py b/django/core/handlers/modpython.py deleted file mode 100644 index fb23fb497a..0000000000 --- a/django/core/handlers/modpython.py +++ /dev/null @@ -1,180 +0,0 @@ -import os -import sys -from warnings import warn - -from django import http -from django.core import signals -from django.core.handlers.base import BaseHandler -from django.core.urlresolvers import set_script_prefix -from django.utils import datastructures -from django.utils.encoding import force_unicode, iri_to_uri -from django.utils.log import getLogger - -logger = getLogger('django.request') - -class ModPythonRequest(http.HttpRequest): - def __init__(self, req): - self._req = req - # FIXME: This isn't ideal. The request URI may be encoded (it's - # non-normalized) slightly differently to the "real" SCRIPT_NAME - # and PATH_INFO values. This causes problems when we compute path_info, - # below. For now, don't use script names that will be subject to - # encoding/decoding. - self.path = force_unicode(req.uri) - root = req.get_options().get('django.root', '') - self.django_root = root - # req.path_info isn't necessarily computed correctly in all - # circumstances (it's out of mod_python's control a bit), so we use - # req.uri and some string manipulations to get the right value. - if root and req.uri.startswith(root): - self.path_info = force_unicode(req.uri[len(root):]) - else: - self.path_info = self.path - if not self.path_info: - # Django prefers empty paths to be '/', rather than '', to give us - # a common start character for URL patterns. So this is a little - # naughty, but also pretty harmless. - self.path_info = u'/' - self._post_parse_error = False - self._stream = self._req - self._read_started = False - - def get_full_path(self): - # RFC 3986 requires self._req.args to be in the ASCII range, but this - # doesn't always happen, so rather than crash, we defensively encode it. - return '%s%s' % (self.path, self._req.args and ('?' + iri_to_uri(self._req.args)) or '') - - def _is_secure(self): - try: - return self._req.is_https() - except AttributeError: - # mod_python < 3.2.10 doesn't have req.is_https(). - return self._req.subprocess_env.get('HTTPS', '').lower() in ('on', '1') - - def _get_request(self): - if not hasattr(self, '_request'): - self._request = datastructures.MergeDict(self.POST, self.GET) - return self._request - - def _get_get(self): - if not hasattr(self, '_get'): - self._get = http.QueryDict(self._req.args, encoding=self._encoding) - return self._get - - def _set_get(self, get): - self._get = get - - def _get_post(self): - if not hasattr(self, '_post'): - self._load_post_and_files() - return self._post - - def _set_post(self, post): - self._post = post - - def _get_cookies(self): - if not hasattr(self, '_cookies'): - self._cookies = http.parse_cookie(self._req.headers_in.get('cookie', '')) - return self._cookies - - def _set_cookies(self, cookies): - self._cookies = cookies - - def _get_files(self): - if not hasattr(self, '_files'): - self._load_post_and_files() - return self._files - - def _get_meta(self): - "Lazy loader that returns self.META dictionary" - if not hasattr(self, '_meta'): - self._meta = { - 'AUTH_TYPE': self._req.ap_auth_type, - 'CONTENT_LENGTH': self._req.headers_in.get('content-length', 0), - 'CONTENT_TYPE': self._req.headers_in.get('content-type'), - 'GATEWAY_INTERFACE': 'CGI/1.1', - 'PATH_INFO': self.path_info, - 'PATH_TRANSLATED': None, # Not supported - 'QUERY_STRING': self._req.args, - 'REMOTE_ADDR': self._req.connection.remote_ip, - 'REMOTE_HOST': None, # DNS lookups not supported - 'REMOTE_IDENT': self._req.connection.remote_logname, - 'REMOTE_USER': self._req.user, - 'REQUEST_METHOD': self._req.method, - 'SCRIPT_NAME': self.django_root, - 'SERVER_NAME': self._req.server.server_hostname, - 'SERVER_PORT': self._req.connection.local_addr[1], - 'SERVER_PROTOCOL': self._req.protocol, - 'SERVER_SOFTWARE': 'mod_python' - } - for key, value in self._req.headers_in.items(): - key = 'HTTP_' + key.upper().replace('-', '_') - self._meta[key] = value - return self._meta - - def _get_method(self): - return self.META['REQUEST_METHOD'].upper() - - GET = property(_get_get, _set_get) - POST = property(_get_post, _set_post) - COOKIES = property(_get_cookies, _set_cookies) - FILES = property(_get_files) - META = property(_get_meta) - REQUEST = property(_get_request) - method = property(_get_method) - -class ModPythonHandler(BaseHandler): - request_class = ModPythonRequest - - def __call__(self, req): - warn(('The mod_python handler is deprecated; use a WSGI or FastCGI server instead.'), - DeprecationWarning) - - # mod_python fakes the environ, and thus doesn't process SetEnv. This fixes that - os.environ.update(req.subprocess_env) - - # now that the environ works we can see the correct settings, so imports - # that use settings now can work - from django.conf import settings - - # if we need to set up middleware, now that settings works we can do it now. - if self._request_middleware is None: - self.load_middleware() - - set_script_prefix(req.get_options().get('django.root', '')) - signals.request_started.send(sender=self.__class__) - try: - try: - request = self.request_class(req) - except UnicodeDecodeError: - logger.warning('Bad Request (UnicodeDecodeError)', - exc_info=sys.exc_info(), - extra={ - 'status_code': 400, - } - ) - response = http.HttpResponseBadRequest() - else: - response = self.get_response(request) - finally: - signals.request_finished.send(sender=self.__class__) - - # Convert our custom HttpResponse object back into the mod_python req. - req.content_type = response['Content-Type'] - for key, value in response.items(): - if key != 'content-type': - req.headers_out[str(key)] = str(value) - for c in response.cookies.values(): - req.headers_out.add('Set-Cookie', c.output(header='')) - req.status = response.status_code - try: - for chunk in response: - req.write(chunk) - finally: - response.close() - - return 0 # mod_python.apache.OK - -def handler(req): - # mod_python hooks into this function. - return ModPythonHandler()(req) diff --git a/django/core/handlers/profiler-hotshot.py b/django/core/handlers/profiler-hotshot.py deleted file mode 100644 index 0522de6d84..0000000000 --- a/django/core/handlers/profiler-hotshot.py +++ /dev/null @@ -1,25 +0,0 @@ -import hotshot -import os -import time - -from django.core.handlers.modpython import ModPythonHandler - -PROFILE_DATA_DIR = "/var/log/cmsprofile" - -def handler(req): - ''' - Handler that uses hotshot to store profile data. - - Stores profile data in PROFILE_DATA_DIR. Since hotshot has no way (that I - know of) to append profile data to a single file, each request gets its own - profile. The file names are in the format ..prof where is - the request path with "/" replaced by ".", and is a timestamp with - microseconds to prevent overwriting files. - - Use the gather_profile_stats.py script to gather these individual request - profiles into aggregated profiles by request path. - ''' - profname = "%s.%.3f.prof" % (req.uri.strip("/").replace('/', '.'), time.time()) - profname = os.path.join(PROFILE_DATA_DIR, profname) - prof = hotshot.Profile(profname) - return prof.runcall(ModPythonHandler(), req) diff --git a/docs/howto/deployment/modpython.txt b/docs/howto/deployment/modpython.txt deleted file mode 100644 index b1ddf581f5..0000000000 --- a/docs/howto/deployment/modpython.txt +++ /dev/null @@ -1,415 +0,0 @@ -============================================ -How to use Django with Apache and mod_python -============================================ - -.. warning:: - - Support for mod_python has been deprecated, and will be removed in - Django 1.5. If you are configuring a new deployment, you are - strongly encouraged to consider using :doc:`mod_wsgi - ` or any of the other :doc:`supported - servers `. - -.. highlight:: apache - -The `mod_python`_ module for Apache_ can be used to deploy Django to a -production server, although it has been mostly superseded by the simpler -:doc:`mod_wsgi deployment option `. - -mod_python is similar to (and inspired by) `mod_perl`_ : It embeds Python within -Apache and loads Python code into memory when the server starts. Code stays in -memory throughout the life of an Apache process, which leads to significant -performance gains over other server arrangements. - -Django requires Apache 2.x and mod_python 3.x, and you should use Apache's -`prefork MPM`_, as opposed to the `worker MPM`_. - -.. seealso:: - - * Apache is a big, complex animal, and this document only scratches the - surface of what Apache can do. If you need more advanced information about - Apache, there's no better source than `Apache's own official - documentation`_ - - * You may also be interested in :doc:`How to use Django with FastCGI, SCGI, - or AJP `. - -.. _Apache: http://httpd.apache.org/ -.. _mod_python: http://www.modpython.org/ -.. _mod_perl: http://perl.apache.org/ -.. _prefork MPM: http://httpd.apache.org/docs/2.2/mod/prefork.html -.. _worker MPM: http://httpd.apache.org/docs/2.2/mod/worker.html -.. _apache's own official documentation: http://httpd.apache.org/docs/ - -Basic configuration -=================== - -To configure Django with mod_python, first make sure you have Apache installed, -with the mod_python module activated. - -Then edit your ``httpd.conf`` file and add the following:: - - - SetHandler python-program - PythonHandler django.core.handlers.modpython - SetEnv DJANGO_SETTINGS_MODULE mysite.settings - PythonOption django.root /mysite - PythonDebug On - - -...and replace ``mysite.settings`` with the Python import path to your Django -project's settings file. - -This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the -Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE -` so mod_python knows which settings to use. - -Because mod_python does not know we are serving this site from underneath the -``/mysite/`` prefix, this value needs to be passed through to the mod_python -handler in Django, via the ``PythonOption django.root ...`` line. The value set -on that line (the last item) should match the string given in the ```` directive. The effect of this is that Django will automatically strip the -``/mysite`` string from the front of any URLs before matching them against your -URLconf patterns. If you later move your site to live under ``/mysite2``, you -will not have to change anything except the ``django.root`` option in the config -file. - -When using ``django.root`` you should make sure that what's left, after the -prefix has been removed, begins with a slash. Your URLconf patterns that are -expecting an initial slash will then work correctly. In the above example, -since we want to send things like ``/mysite/admin/`` to ``/admin/``, we need -to remove the string ``/mysite`` from the beginning, so that is the -``django.root`` value. It would be an error to use ``/mysite/`` (with a -trailing slash) in this case. - -Note that we're using the ```` directive, not the ```` -directive. The latter is used for pointing at places on your filesystem, -whereas ```` points at places in the URL structure of a Web site. -```` would be meaningless here. - -Also, if your Django project is not on the default ``PYTHONPATH`` for your -computer, you'll have to tell mod_python where your project can be found: - -.. parsed-literal:: - - - SetHandler python-program - PythonHandler django.core.handlers.modpython - SetEnv DJANGO_SETTINGS_MODULE mysite.settings - PythonOption django.root /mysite - PythonDebug On - **PythonPath "['/path/to/project'] + sys.path"** - - -The value you use for ``PythonPath`` should include the parent directories of -all the modules you are going to import in your application. It should also -include the parent directory of the :ref:`DJANGO_SETTINGS_MODULE -` location. This is exactly the same situation as -setting the Python path for interactive usage. Whenever you try to import -something, Python will run through all the directories in ``sys.path`` in turn, -from first to last, and try to import from each directory until one succeeds. - -Make sure that your Python source files' permissions are set such that the -Apache user (usually named ``apache`` or ``httpd`` on most systems) will have -read access to the files. - -An example might make this clearer. Suppose you have some applications under -``/usr/local/django-apps/`` (for example, ``/usr/local/django-apps/weblog/`` and -so forth), your settings file is at ``/var/www/mysite/settings.py`` and you have -specified :ref:`DJANGO_SETTINGS_MODULE ` as in the above -example. In this case, you would need to write your ``PythonPath`` directive -as:: - - PythonPath "['/usr/local/django-apps/', '/var/www'] + sys.path" - -With this path, ``import weblog`` and ``import mysite.settings`` will both -work. If you had ``import blogroll`` in your code somewhere and ``blogroll`` -lived under the ``weblog/`` directory, you would *also* need to add -``/usr/local/django-apps/weblog/`` to your ``PythonPath``. Remember: the -**parent directories** of anything you import directly must be on the Python -path. - -.. note:: - - If you're using Windows, we still recommended that you use forward - slashes in the pathnames, even though Windows normally uses the backslash - character as its native separator. Apache knows how to convert from the - forward slash format to the native format, so this approach is portable and - easier to read. (It avoids tricky problems with having to double-escape - backslashes.) - - This is valid even on a Windows system:: - - PythonPath "['c:/path/to/project'] + sys.path" - -You can also add directives such as ``PythonAutoReload Off`` for performance. -See the `mod_python documentation`_ for a full list of options. - -Note that you should set ``PythonDebug Off`` on a production server. If you -leave ``PythonDebug On``, your users would see ugly (and revealing) Python -tracebacks if something goes wrong within mod_python. - -Restart Apache, and any request to ``/mysite/`` or below will be served by -Django. Note that Django's URLconfs won't trim the "/mysite/" -- they get passed -the full URL. - -When deploying Django sites on mod_python, you'll need to restart Apache each -time you make changes to your Python code. - -.. _mod_python documentation: http://modpython.org/live/current/doc-html/directives.html - -Multiple Django installations on the same Apache -================================================ - -It's entirely possible to run multiple Django installations on the same Apache -instance. Just use ``VirtualHost`` for that, like so:: - - NameVirtualHost * - - - ServerName www.example.com - # ... - SetEnv DJANGO_SETTINGS_MODULE mysite.settings - - - - ServerName www2.example.com - # ... - SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings - - -If you need to put two Django installations within the same ``VirtualHost`` -(or in different ``VirtualHost`` blocks that share the same server name), -you'll need to take a special precaution to ensure mod_python's cache doesn't -mess things up. Use the ``PythonInterpreter`` directive to give different -```` directives separate interpreters:: - - - ServerName www.example.com - # ... - - SetEnv DJANGO_SETTINGS_MODULE mysite.settings - PythonInterpreter mysite - - - - SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings - PythonInterpreter othersite - - - -The values of ``PythonInterpreter`` don't really matter, as long as they're -different between the two ``Location`` blocks. - -Running a development server with mod_python -============================================ - -If you use mod_python for your development server, you can avoid the hassle of -having to restart the server each time you make code changes. Just set -``MaxRequestsPerChild 1`` in your ``httpd.conf`` file to force Apache to reload -everything for each request. But don't do that on a production server, or we'll -revoke your Django privileges. - -If you're the type of programmer who debugs using scattered ``print`` -statements, note that output to ``stdout`` will not appear in the Apache -log and can even `cause response errors`_. - -.. _cause response errors: http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html - -If you have the need to print debugging information in a mod_python setup, you -have a few options. You can print to ``stderr`` explicitly, like so:: - - print >> sys.stderr, 'debug text' - sys.stderr.flush() - -(note that ``stderr`` is buffered, so calling ``flush`` is necessary if you wish -debugging information to be displayed promptly.) - -A more compact approach is to use an assertion:: - - assert False, 'debug text' - -Another alternative is to add debugging information to the template of your page. - -Serving media files -=================== - -Django doesn't serve media files itself; it leaves that job to whichever Web -server you choose. - -We recommend using a separate Web server -- i.e., one that's not also running -Django -- for serving media. Here are some good choices: - -* lighttpd_ -* Nginx_ -* TUX_ -* A stripped-down version of Apache_ -* Cherokee_ - -If, however, you have no option but to serve media or static files on the -same Apache ``VirtualHost`` as Django, here's how you can turn off mod_python -for a particular part of the site:: - - - SetHandler None - - -Just change ``Location`` to the root URL of your media files. You can also use -```` to match a regular expression. - -This example sets up Django at the site root but explicitly disables Django -for the ``media`` and ``static`` subdirectories and any URL that ends with -``.jpg``, ``.gif`` or ``.png``:: - - - SetHandler python-program - PythonHandler django.core.handlers.modpython - SetEnv DJANGO_SETTINGS_MODULE mysite.settings - - - - SetHandler None - - - - SetHandler None - - - - SetHandler None - - -.. _lighttpd: http://www.lighttpd.net/ -.. _Nginx: http://wiki.nginx.org/Main -.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server -.. _Apache: http://httpd.apache.org/ -.. _Cherokee: http://www.cherokee-project.com/ - -Serving the admin files -======================= - -Note that the Django development server automagically serves the static files -of the admin app, but this is not the case when you use any other server -arrangement. You're responsible for setting up Apache, or whichever media -server you're using, to serve the admin files. - -The admin files live in (:file:`django/contrib/admin/static/admin`) of the -Django distribution. - -We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle the -admin files (this means using the :djadmin:`collectstatic` management command -to collect the static files in :setting:`STATIC_ROOT`, and then configuring -your Web server to serve :setting:`STATIC_ROOT` at :setting:`STATIC_URL`), but -here are two other approaches: - -1. Create a symbolic link to the admin static files from within your - document root. - -2. Or, copy the admin static files so that they live within your Apache - document root. - -Using "eggs" with mod_python -============================ - -If you installed Django from a Python egg_ or are using eggs in your Django -project, some extra configuration is required. Create an extra file in your -project (or somewhere else) that contains something like the following: - -.. code-block:: python - - import os - os.environ['PYTHON_EGG_CACHE'] = '/some/directory' - -Here, ``/some/directory`` is a directory that the Apache Web server process can -write to. It will be used as the location for any unpacking of code the eggs -need to do. - -Then you have to tell mod_python to import this file before doing anything -else. This is done using the PythonImport_ directive to mod_python. You need -to ensure that you have specified the ``PythonInterpreter`` directive to -mod_python as described above__ (you need to do this even if you aren't -serving multiple installations in this case). Then add the ``PythonImport`` -line in the main server configuration (i.e., outside the ``Location`` or -``VirtualHost`` sections). For example:: - - PythonInterpreter my_django - PythonImport /path/to/my/project/file.py my_django - -Note that you can use an absolute path here (or a normal dotted import path), -as described in the `mod_python manual`_. We use an absolute path in the -above example because if any Python path modifications are required to access -your project, they will not have been done at the time the ``PythonImport`` -line is processed. - -.. _Egg: http://peak.telecommunity.com/DevCenter/PythonEggs -.. _PythonImport: http://www.modpython.org/live/current/doc-html/dir-other-pimp.html -.. _mod_python manual: PythonImport_ -__ `Multiple Django installations on the same Apache`_ - -Error handling -============== - -When you use Apache/mod_python, errors will be caught by Django -- in other -words, they won't propagate to the Apache level and won't appear in the Apache -``error_log``. - -The exception for this is if something is really wonky in your Django setup. In -that case, you'll see an "Internal Server Error" page in your browser and the -full Python traceback in your Apache ``error_log`` file. The ``error_log`` -traceback is spread over multiple lines. (Yes, this is ugly and rather hard to -read, but it's how mod_python does things.) - -If you get a segmentation fault -=============================== - -If Apache causes a segmentation fault, there are two probable causes, neither -of which has to do with Django itself. - -1. It may be because your Python code is importing the "pyexpat" module, - which may conflict with the version embedded in Apache. For full - information, see `Expat Causing Apache Crash`_. - -2. It may be because you're running mod_python and mod_php in the same - Apache instance, with MySQL as your database backend. In some cases, - this causes a known mod_python issue due to version conflicts in PHP and - the Python MySQL backend. There's full information in the - `mod_python FAQ entry`_. - -If you continue to have problems setting up mod_python, a good thing to do is -get a barebones mod_python site working, without the Django framework. This is -an easy way to isolate mod_python-specific problems. `Getting mod_python Working`_ -details this procedure. - -The next step should be to edit your test code and add an import of any -Django-specific code you're using -- your views, your models, your URLconf, -your RSS configuration, etc. Put these imports in your test handler function -and access your test URL in a browser. If this causes a crash, you've confirmed -it's the importing of Django code that causes the problem. Gradually reduce the -set of imports until it stops crashing, so as to find the specific module that -causes the problem. Drop down further into modules and look into their imports, -as necessary. - -.. _Expat Causing Apache Crash: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash -.. _mod_python FAQ entry: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp -.. _Getting mod_python Working: http://www.dscpl.com.au/wiki/ModPython/Articles/GettingModPythonWorking - -If you get a UnicodeEncodeError -=============================== - -If you're taking advantage of the internationalization features of Django (see -:doc:`/topics/i18n/index`) and you intend to allow users to upload files, you must -ensure that the environment used to start Apache is configured to accept -non-ASCII file names. If your environment is not correctly configured, you -will trigger ``UnicodeEncodeError`` exceptions when calling functions like -``os.path()`` on filenames that contain non-ASCII characters. - -To avoid these problems, the environment used to start Apache should contain -settings analogous to the following:: - - export LANG='en_US.UTF-8' - export LC_ALL='en_US.UTF-8' - -Consult the documentation for your operating system for the appropriate syntax -and location to put these configuration items; ``/etc/apache2/envvars`` is a -common location on Unix platforms. Once you have added these statements -to your environment, restart Apache.