I am using the middleware provided in https://gist.github.com/426829 to do cross site scripting.
However, when I add the middleware to MIDDLEWARE_CLASSES, I get the error:
ImproperlyConfigured: isn't a middleware module.
My MIDDLEWARE_CLASSES looks like this:
MIDDLEWARE_CLASSES = ('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'TempMiddleware',)
I have not changed any code in the gist. process_request and process_response methods are there. I am on Ubuntu running the latest versions of Python and Django.
What's TempMiddleware? The name of the module, or the name of the class? As you can see with the other entries, you need the fully-qualified Python path of the actual class. If TempMiddleware is the name of the module, you need TempMiddleware.MyMiddlewareClass (and you should really follow PEP8 naming conventions) - and if it's the name of the class, you need my_module.TempMiddleware.
Edit:
TempMiddleware is not importable. It's the name of the class, you must put the entire import path.
E.g:
'django.contrib.auth.middleware.AuthenticationMiddleware'
and not
'AuthenticationMiddleware'
So if your class is in app_name/middleware.py, it should be
app_name.middlaware.TempMiddleware
It just mean that in your settings file, the variable MIDDLEWARE_CLASSES contains a list of modules in which one of the listed module is not a middleware.
Possible causes:
you added a middleware that doesn't declare middleware methods: fix that by removing the last middleware you added
you added a correct middleware but forget to put a coma at the end of the name, so strings are concatenated and it make django thinks 2 middlewares are in fact one: fix that by adding the missing coma
Related
I'm trying to set up a Django application that will accept multiple subdomain URLs. I'd like to test this locally. Since I can't nail this first step of passing in a url that has a subdomain, I can't get to the second part (figuring out if the URLconf I've set up for django-subdomains is working). The middleware checks for a subdomain, and chooses a URLconf file based on that subdomain.
I've set the following configs in /etc/hosts. When I've got the server running, and I hit these URLs, I go to the real test.com.
127.0.0.1 payments.test.com
127.0.0.1 rampup.test.com
(in case it matters) django-subdomains middleware settings from settings.py:
SUBDOMAIN_URLCONFS = {
'payments': 'main.urls',
'rampup': 'rampup.urls'
}
MIDDLEWARE_CLASSES = (
'subdomains.middleware.SubdomainURLRoutingMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
# Uncomment the next line for simple clickjacking protection:
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
Try this:
0.0.0.0 payments.test.com
0.0.0.0 rampup.test.com
I'm getting the following message. I somewhat understand that my project server cannot find the templates. However, I have no idea exactly what it's complaining about the templates. Would be great to hear alternate explanations of what's happening.
Environment:
Request Method: GET
Request URL: http://127.0.0.1:8000/polls/1/
Django Version: 1.4
Python Version: 2.7.3
Installed Applications:
('django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'polls',
'django.contrib.admin')
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware')
Template Loader Error:
Django tried loading these templates, in this order:
Using loader django.template.loaders.filesystem.Loader:
/home/stanley/mytemplates/polls/detail.html, polls/poll_detail.html (File does not exist)
Using loader django.template.loaders.app_directories.Loader:
/usr/local/lib/python2.7/dist-packages/django/contrib/auth/templates/polls/detail.html, polls/poll_detail.html (File does not exist)
/usr/local/lib/python2.7/dist-packages/django/contrib/admin/templates/polls/detail.html, polls/poll_detail.html (File does not exist)
Traceback:
File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py" in get_response
136. response = response.render()
File "/usr/local/lib/python2.7/dist-packages/django/template/response.py" in render
104. self._set_content(self.rendered_content)
File "/usr/local/lib/python2.7/dist-packages/django/template/response.py" in rendered_content
79. template = self.resolve_template(self.template_name)
File "/usr/local/lib/python2.7/dist-packages/django/template/response.py" in resolve_template
55. return loader.select_template(template)
File "/usr/local/lib/python2.7/dist-packages/django/template/loader.py" in select_template
193. raise TemplateDoesNotExist(', '.join(not_found))
Exception Type: TemplateDoesNotExist at /polls/1/
Exception Value: polls/detail.html, polls/poll_detail.html
I'll try to answer this in a bit more depth, especially to react to your statement "I think i got the templates in the wrong place." This can be easily solved using the traceback you posted.
First thing it tells you is some stuff about your environment - you can simply ignore this. This is not usefull for a TemplateLoaderError. It can be important though if any of your apps requires a special version of Python or something the like.
Next thing to spot is what kind of error has ocurred, and this one is extremely helpfull for your special case:
Template Loader Error:
Django tried loading these templates, in this order:
Using loader django.template.loaders.filesystem.Loader:
/home/stanley/mytemplates/polls/detail.html, polls/poll_detail.html (File does not exist)
If you take a closer look at this one, it tells you exactly where Django tried to find the specified templates, and what happened while it was looking for them (File does not exist). This will help you to find a solution to check if you really got your templates in the wrong place (which will happen quite often, even to a bit more experienced Django developers).
The next part is the traceback. You can savely ignore it in your case, because there is no file involved that is located in your project folder. If it was, that would mean you possibly screwed up something in the named file, and Django even tells you in which line your code did (possibly) provoke the exception.
Last part is information about the exception that has been raised, in your case TemplateDoesNotExist. Django has some special exceptions that you can find here . Other than these Django raises the standard Python exceptions.
Hope i didn't tell you too much you allready knew.
Do you have something like this in your settings?
PROJECT_ROOT = path.dirname(path.abspath(__file__)) #gets directory settings is in
TEMPLATE_DIRS = (
PROJECT_ROOT+'/templates',
)
You might have specified some path in your TEMPLATE_DIRS tuple in settings.py file.Django searches the html templates only in those directories.So add the following path to your TEMPLATE_DIRS.
TEMPLATE_DIRS = ('/polls',)
Problem: When I add UpdateCacheMiddleware and FetchFromCacheMiddleware to my Django project, I get unittest failures. This is regardless of the CACHE_BACKEND I use (right now I am using locmem://, but the errors are the same when I use file:///path_to_cache)
My Middleware:
MIDDLEWARE_CLASSES = (
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
)
All my test failures look like the one below: 'NoneType' object is unsubscriptable
======================================================================
Error: test_last_login (django.contrib.auth.tests.remote_user.RemoteUserTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Python26\lib\site-packages\django\contrib\auth\tests\remote_user.py",
line 87, in test_last_login
self.assertNotEqual(default_login, response.context['user'].last_login)
TypeError: 'NoneType' object is unsubscriptable
I must be missing something (or doing something wrong) as I have searched around the web for this issue, but no one seems to have encountered it.
Steps to Reproduce:
Start a new django project (django-admin.py startproject myproject) and configure settings.py
Add CACHE_BACKEND to settings.py and add the two Cache Middlewares from Django
Run python manage.py test
Notes: There is only one test failure when using dummy:// cache and it is documented at: http://code.djangoproject.com/ticket/11640
The solution to the failing tests is to set CACHE_MIDDLEWARE_SECONDS to 0 (e.g. set this to be 0 in your dev environment). This will allow the django.contrib tests to all pass.
I have a couple of projects in Django and alternate between one and another every now and then. All of them have a /media/ path, which is served by django.views.static.serve, and they all have a /media/css/base.css file.
The problem is, whenever I run one project, the requests to base.css return an HTTP 304 (not modified), probably because the timestamp hasn't changed. But when I run the other project, the same 304 is returned, making the browser use the file cached by the previous project (and therefore, using the wrong stylesheet).
Just for the record, here are the middleware classes:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.transaction.TransactionMiddleware',
)
I always use the default address http://localhost:8000.
Is there another solution (other than using different ports - 8001, 8002, etc.)?
You can roll your own middleware for that:
class NoIfModifiedSinceMiddleware(object):
def process_request(self, request):
request.META.pop('HTTP_IF_MODIFIED_SINCE', None)
Basically, it just removes HTTP_IF_MODIFIED_SINCE header from the request.
Afterthought: Or you can monkeypatch django.views.static.serve and replace was_modified_since function by the one, that always returns True.
I have created translation strings in the template and in the application view.
Then I ran:
django-admin.py makemessages -l it
and the file it/LC_MESSAGES/django.po has been created
I have now translated strings in the django.po file, and then I ran:
django-admin.py compilemessages
And I receive:
processing file django.po in /home/jobber/Desktop/library/books/locale/it/LC_MESSAGES
My settings.py looks like this:
LANGUAGE_CODE = 'it'
TEMPLATE_CONTEXT_PROCESSORS = ( "django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media", )
USE_I18N = True
MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
)
but I still always see English text. Why?
Maybe your browser language is English. The LocaleMiddleware tries to detect the language based on this algorithm (i.e. Accept-Language HTTP header).
So you can either remove the LocaleMiddleware to avoid this or use the set_language redirect view.
In addition to the accepted answer: If you're using Firefox you can install Quick Locale Switcher to test your application with different languages (based on the browser language). It adds a button at the bottom of your screen where you can easily change your browser language.